30-23 之 Patterns of Enterprise Application Architecture 小总结

今天我们简单来整理一下，这几个星期从《 Patterns of Enterprise Application Architecture - Martin Fowler 》这本书中所学习到的东西，先简单来张图。

这张图涵盖了我们前几天所讨论的东西。

Presentation Layer

这个层级是专门用来处理画面的地方，书中虽然以模式来说只要提到 MVC，但是因为我觉得现在应该还蛮多人也有听过 MVP 与 MVVM 所以我也一起拿来说一下。

MVC : 最常听到，也是有最多版本的模式，最传统的 MVC 三者 Model、View、Controller 是会相互有交集的，而不是 ASP.NET MVC 那种 View → Controller → Model。
MVP : 为了解除 View 与 Model 的耦合，双方沟通完全改由 Presenter 来处理，我个人觉得 ASP.NET MVC 比较像这个。
MVVM : 其中 VM ViewModel 实现了画面与资料的双向绑定，现在很多前端 framework 都是以这个概念来实现。

Presentation layer 与 domain layer 之间我们有提到两个东西 :

会有这两个东西主要原因在於 :

画面要的东西，不见得与 domain 层的形状一样

所以 remote facade 是一种设计模式，来让『外部使用更简单』，而 DTO 本质上就是一个传送给外部的物件，他的形状比较接近 Presentation 需要用到的。

这里主要有三种模式 :

Transaction script : 基本就是一个业务，想办法完成就对了。
Domain model : 建立不同的 domain，然後该由那个 domain 处理的部份就由他来，与上面 transaction script 相比，我觉得重点在於职则分明。
Table module : 以每个资料表为一个类别，然後里面提到与之对应的操作。

上面的 domain model 与 table module 事实上会有一个问题，那就是要在那里串业务流程，以 domain model 来看职则分明，但问题是一定要有个地方来串啊 ? 对这就是 service。

然後这里我们还有提到几个我觉得算是 domain layer 的支援工具 :

UnitOfWork : 处理 transaction 的地方。
Repository : 我们很多时後，会有很多因为业务上的需要，所需要的一些资料库特殊的操作，例如 select 某些特别要用的栏位，这种为了业务而写的 query 就是放在 repository。没有他 dataSource 层的形状，就会慢慢和 domain 混在一起。
LazyLoading : 有一些资料，只有在需要时才需要 load 出来，如果每一次使用 domain 都要 load 所有资料，那会有性能瓶颈的。

这里就是专门处理与资料库相关的操作，而不代有业务逻辑。

TableDataGateway : 每个物件都以表为单位，来提供操作。
RowDataGateway : 每个物件以 row 为单位，来提供操作。
Active Record: 以 table 为单位，来提供包含『业务』相关的操作，我觉得很接近 repository 想解决的事情。
Data Mapper : 专门提供资料库操作并且与 domain model 一起使用，而且他可以跨表，因为它主要回传的东西以 domain model 为单位，而 domain model 没有限定只能一张表。

《 Patterns of Enterprise Application Architecture - Martin Fowler 》这本书应该就先到这一段落了，虽然还有很多可以降，但接下来我想先往 domain layer 那在继续的往以下两个地方延伸了 :