评论：企业应用程序架构模式 - 第1部分（共3部分）

1 引言

Martin Fowler 的《企业应用架构模式》(PEAA) 这本书的组织方式不像一般的技术书籍。相反，前 106 页涵盖了一些过去、现在和未来用于企业应用程序设计中最常见模式的高级概述。其余 500 多页分为 10 章，详细介绍了 51 种不同的设计模式。

由于 PEAA 的格式，对这本书进行标准的书评将无法充分展现其价值。相反，我打算对这本书中我使用过的一些模式提供一些反馈。在本文以及接下来的两篇文章中，我希望为你提供一个实际示例，说明 Martin 的书中的一些模式是如何使用的，需要考虑的事项，以及要避免的问题。我将介绍的一些模式在我阅读这本书之前就已经接触过，另一些则是直接摘自 PEAA 的内容。

我在这里将要介绍的所有模式都曾/正在一个部署了 30 多个实例的 Web 框架中使用。这个 Web 框架由数据访问层、一些继承的控件和一些页面处理器组成。它还非常模块化。对于这个特定的框架，我没有参与初始设计，所以可能无法提供为什么当时选择特定模式的见解。相反，我将尝试分析为什么它在当今环境中表现良好或不佳。本书评论的任何部分都不是为了推销该产品。我提到它只是因为我认为它能为读者提供一个关于这些模式使用环境的良好背景。

最后一点澄清，我并不是要将自己描绘成一位你应该奉为圭臬的资深应用程序设计者。事实上，我更倾向于相反的说法。我使用预定设计模式的经验仅限于少数几个项目，其中只有少数几个是我作为初始或持续的“架构师”。

哦，本文中括号内的数字指的是书中的页码。当你购买这本书时，你会在书中看到同样的标注。我们开始吧！

2 领域逻辑模式

2.1 领域模型 (116)

在我们的框架中，最初的目标是创建一个代码库，该代码库可以让我们快速构建一个具有所有核心功能（页面管理、安全性等）的网站，同时还能轻松扩展核心对象以满足特定客户的需求。这是通过实现 Fowler 的“富领域模型”定义来实现的，使用了数据映射器 (165)。

如果你查看我们的领域层，你会发现完全没有数据库代码。相反，你会找到基础对象的模型、缓存机制以及需要在框架最高级别运行的一些其他功能。之所以缺少数据操作代码，是因为我们实现了数据映射器 (165) 模式。我将在本文后面详细讨论这个问题。

我们最初的领域模型 (116) 实现并不完美。正如 Fowler 所说，保持领域层与其他所有层分离非常重要。我们最初的几个项目，可以说并不完美。在我们意识到服务层 (133) 的重要性之前，UI 层与领域层紧密耦合。改变非常困难，而且现有应用程序的回归测试经常因领域层的破坏性更改而失败。因此，很明显每个项目都需要某种业务层。我们很快意识到，尽管这个领域模型 (116) 提供了添加特定于客户端的新对象的能力；但如果没有影响到所有使用我们框架的应用程序，就很难扩展现有对象。

2.2 服务层 (133)

正如我之前提到的，我们很早就意识到，如果我们找不到实现某种业务层的方法，我们的框架将无法长久生存，也无法实现其预期目的。正是在这个时候，我阅读了 PEAA 书籍，并意识到服务层 (133) 模式正是我们所需要的。特别是 Fowler 所描述的“领域外观”。这是一个服务层，它实现了领域模型 (116) 的一套精简外观。

最简单的形式，服务层 (133) 就是一个业务逻辑层。通过实现服务层 (133) 模式，我们现在可以将 100% 的客户端特定代码排除在领域模型 (116) 之外，从而获得更大的灵活性，并大大减少每次更改所需的回归测试量。

我们实现服务层 (133) 的最初几个项目花费了一些时间。这并非由于模式的复杂性，更多的是因为我们不得不回过头来为现有项目创建服务层 (133)，从领域模型 (116) 中剥离客户端特定代码，然后重新测试。尽管这次重构花费了大量时间，但对团队来说也很有价值。它让我们对如何规划未来的增强有了很多了解，也有助于整个团队更好地理解领域模型 (116)，因为并非所有开发人员都参与了其初始创建。

我们最初的几个服务层 (133) 设计并不完美。起初，我们的 UI 直接调用领域模型 (116) 和服务层 (133) 中的方法，有时甚至在同一个方法中。这很快就成了一个问题，我们决定所有对象迭代必须只通过服务层 (133)。这有助于减少我们在测试中遇到的一些问题，特别是我们遇到的类型转换问题。

3 数据源架构模式

3.1 数据映射器 (165)

数据映射器 (165) 模式是许多魔法发生的地方。Fowler 极好地定义了一个数据映射器 (165) 应该包含什么，不应该包含什么。虽然我没有参与我们框架的初始设计，但我能够回顾并清楚地看到数据映射器 (165) 模式为何被实现。由于数据映射器 (165) 模式，我们的领域模型 (116) 和服务层 (133) 完全不知道数据源。这使我们能够灵活地使用任何我们想要的数据源。我们目前支持 MSSQL 和 Oracle，但如果我们想使用 MySQL，就不需要重写整个领域模型 (116)。我们只需要创建一个新的数据映射器 (165) 集，就可以继续工作了。

Martin 还描述了几种实现数据映射器 (165) 模式的方法。一种是单映射器方法。正如他所描述的，这只有在你的代码库也实现了元数据映射器 (306) 时才理想。由于我们的代码库没有，我们选择在我们的领域模型 (116) 和服务层 (133) 中为每个对象实现一个数据映射器 (165)。

结语

到此，我的第一个 CodeProject 文章就结束了。我将跟进写另外两篇文章。下一篇将重点介绍对象-关系行为模式和对象-关系结构模式，最后一篇文章将涵盖 Web 表示模式。

我期待你们的反馈。我不在乎你认为我做得很好，还是认为我应该删除它。请给我反馈！感谢你的时间，希望你喜欢这篇文章。