在数据访问层和业务层上实现哪种模式？答案

【问题标题】：Which pattern to implement on Data access layer and on the business layer?在数据访问层和业务层上实现哪种模式？
【发布时间】：2013-06-30 21:53:39
【问题描述】：

我正在创建一个这样的 4 层项目

数据访问层
业务逻辑层
仅包含与我的实体相关的 POCO 类的域模型（通过 EF5）
网站作为前端

到目前为止，我一直将 DAL 和 BLL 混合在一起，并直接从网站上引用 DAL。这一次，我想在这里进行一些真正的关注点分离，我想创建一个 DAL，它是一个真正的 DAL 和可单元测试的 DAL，再加上一个真正与持久性无关的 BLL（你知道，就像专业人士那样）我正在计划关于使用 EF5

我看过很多类似的网站

soo 基本上我知道我必须使用工厂、存储库和工作单元模式，但我不知道什么去哪里以及什么是我可以遵循的简单（但足够清楚的例子）

我知道的是，我不应该在网站上引用 DAL，因为我真的不知道如何搭建桥梁。

有没有这样的例子，比如 Product 和 Order 表？

【问题讨论】：

标签： asp.net entity-framework design-patterns repository-pattern factory-pattern

【解决方案1】：

soo 基本上我知道我必须使用工厂、存储库和工作单元模式，但我不知道什么在哪里，什么是简单（但足够清楚的例子）我可以遵循

你说你知道你必须使用它们，但你有一个确切的想法为什么你首先需要它们中的每一个吗？ ;)

你没有采取错误的方法来模仿“专业人士”的做法并将所有这些模式一次性扔到你的系统上吗？也许您可以根据更一般的原则开始编写满足您要求的最简单、最天真的实现（可测试的 DAL + 忽略持久性的 BLL）。

设计模式只是达到目的的一种手段。在设计或尝试改进您的实施时，您可能会觉得需要它们，但可能并非如此。

就良好的通用应用程序架构指南而言，我推荐 Bob 大叔在 Clean Architecture 上的工作。我发现，即使他用自己的词汇来描述特定的软件结构，他解释它们的方式也让你很容易将它们视为占位符——你以后可以将它们等同于存储库、工作单元等的一般概念开。

【讨论】：

【解决方案2】：

构建Presentation Layer（网络应用程序）引用的Service Layer。然后在Service Layer 中，您有对BLL、EF5 Entities 和DAL 的引用。 Service Layer 可以只是一个Class Library（例如ASP.NET Web API）或Web Services 层（例如WCF）。

现在您的 Web 应用程序没有对 DAL 的硬引用，而是只知道 Service Layer 和 EF5 Entities。

【讨论】：

【解决方案3】：

我相信你正在搜索the onion architecture。

...洋葱的“核心”是对象模型，它代表您的领域。该层将包含您的 POCO 实体。围绕您的域实体的是存储库接口，而这些接口又被服务接口包围。将您的存储库和服务表示为接口将消费者与具体实现分离，使您能够在不影响消费者（例如客户端 UI 或测试）的情况下将一个交换为另一个。数据访问层在外层中表示为一组实现存储库接口的存储库类。类似地，日志组件在服务接口层实现了一个日志接口。

(from here)

您还应该考虑探索控制/依赖注入的反转。几个月前，我采用了 SimpleInjector（参见 here 和 here）。 SimpleInjector 背后的 man 有一些启发性的帖子可以帮助您 (starting with this one)。

【讨论】：