我正在创建一个像这样的4层项目
我一直把DAL和BLL混合在一起并直接从网站引用DAL。这一次,我想在这里有一些真正的关注点分离,我想创建一个DAL,这是一个真正的DAL和单元可测试加上一个真正持久性不可知的BLL(你知道,就像专业人士那样)我正在筹划关于使用EF5
我读过很多像
这样的网站我所知道的是我不应该在网站上引用DAL而我真的不知道如何制作这座桥。
有没有这样的例子,比如产品和订单表?
答案 0 :(得分:1)
构建Service Layer
(网络应用)引用的Presentation Layer
。然后在Service Layer
中,您引用了BLL
,EF5 Entities
和DAL
。 Service Layer
可以只是Class Library
(例如ASP.NET Web API
)或Web Services
图层(例如WCF
)。
现在,您的网络应用程序没有对DAL
的硬性引用,而只知道Service Layer
和EF5 Entities
。
答案 1 :(得分:1)
我相信您正在搜索the onion architecture。
......洋葱的“核心”是对象模型,代表您的域名。该图层将包含您的POCO实体。您的域实体周围是存储库接口,而存储接口又由服务接口包围。将您的存储库和服务表示为接口将消费者与具体实现分离,使您能够在不影响消费者的情况下将其中一个替换为另一个,例如客户端UI或测试。数据访问层在外层表示为一组实现存储库接口的存储库类。类似地,日志记录组件在服务接口层中实现日志记录接口。
您还应该考虑探索控制/依赖注入的反转。几个月前我采用了SimpleInjector(参见here和here)。 SimpleInjector背后的man有一些启发性的帖子可以帮助你(starting with this one)。
答案 2 :(得分:0)
基本上我知道我必须使用工厂,存储库和 单位的工作模式,但我不知道什么是什么,什么是什么 简单(但足够清楚的例子)我可以按照
你说你知道你必须使用它们但是你有一个确切的想法为什么你首先需要它们? ;)
你是不是采取了错误的方法试图模仿“专业人士”如何做,并立即在你的系统中抛出所有这些模式?也许你可以根据更一般的原则开始编写满足你的要求的最简单,最天真的实现(可测试的DAL +持久性无知的BLL)。
设计模式只是达到目的的手段。在设计或尝试改进实施时,您可能会觉得需要它们,但可能情况并非如此。
就良好的通用应用程序架构指南而言,我建议Bob叔叔在Clean Architecture上的工作。我发现,即使他用他自己的词汇来描述特定的软件结构,他解释它们的方式也使你很容易将它们视为占位符 - 一般概念你可以在以后等同于存储库,工作单元等等。上。