asp.net - 在数据访问层和业务层上实现哪种模式？

Question

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

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

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

我读过很多网站，比如

• http://architects.dzone.com/articles/implementing-repository
• http://www.codeproject.com/Articles/37155/Implementing-Repository-Pattern-With-Entity-Framew
• http://www.codeguru.com/csharp/article.php/c19335/Guide-to-Implement-the-Factory-Pattern-in-C.htm
• http://geekswithblogs.net/cdpcodingblog/archive/2012/04/17/a-simple-pattern-to-separate-business-logic-from-data-access.aspx
• http://blogs.microsoft.co.il/blogs/gilf/archive/2008/05/03/abstract-factory-pattern.aspx
• http://www.dotnetrangers.net/2011/05/01/common-design-patterns-in-c-4-0-part2-abstract-factory-pattern/
• 在业务层中使用工作单元/存储库的正确方法是什么？
• Entity Framework 和 MVC 在业务层或数据访问层创建 DbContext

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

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

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

Answer 1

构建（网络应用Service Layer程序Presentation Layer）引用的。然后在Service Layer你有一个参考BLL,EF5 Entities和DAL。Service Layer可以只是一个（例如）或一个层（Class Library例如）。ASP.NET Web APIWeb ServicesWCF

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

Answer 2

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

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

您是否在尝试模仿“专业人士”的做法并立即将所有这些模式扔给您的系统时，是否采取了错误的方法？也许您可以开始根据更一般的原则编写满足您要求的最简单、最天真的实现（可测试的 DAL + 不了解持久性的 BLL）。

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

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

Answer 3

我相信您正在寻找洋葱架构。

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

（从这里）

您还应该考虑探索控制/依赖注入的反转。几个月前，我采用了 SimpleInjector（参见此处和此处）。SimpleInjector背后的人有一些启发性的帖子可以帮助你（从这个开始）。