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/

What is the correct way to use Unit of Work/Repositories within the business layer?

Entity Framework and MVC create DbContext in business layer or data access layer

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

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

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

Answer 1

soo basically i know i´ll have to use the factory, the repository and unit of work patterns but i dont know what goes where and what is a simple (but clear enough example) i could follow

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

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

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

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