Dav*_*uge 5 c# architecture asp.net oop
我正在尝试创建一个松散耦合,高度可测试,具有良好干净代码等的小型演示Web应用程序.简而言之,我正在尝试以正确的方式做事.;)
我目前在Wolfie解决方案中有三个项目:
目前,Core对任何其他项目都一无所知.数据必须引用Core,因为Core具有Data将返回的类型.所以在这一点上,我发现自己意识到Web需要引用Core和Data才能工作,因为实体类型在Core中,数据库调用在Data中.
Data中的所有存储库类都具有接口,因此可以模拟存储库以进行测试.
我不认为我想将任何特定于数据库的代码或引用放入Core中,并且我希望将实体业务规则保留在Data之外.
从Web引用这两个项目是否正确？或者是否需要Web和其他项目之间的另一个项目,以便Web仅引用一个地方,然后不负责调用数据方法等.
我的目标是一个架构,我的核心应用程序独立于数据层和Web层.
我希望我已经有所了解,我期待一些有用的回复.
我认为您正在努力实现一个合理的目标,这将创建一个可靠的应用程序架构.我个人致力于使用与您描述的类似架构的企业Web应用程序,并且它对该应用程序非常有效.
在该应用程序中,域业务逻辑在其自己的"域"程序集(您的"核心"程序集)中被隔离,并且在.NET框架之外没有引用任何内容.为了连接到外部业务组件,例如数据库和其他Web服务,有一个"基础结构"程序集(您的"数据"程序集).该应用程序的关键是基础结构程序集中的每个实现都在域程序集中进行了接口,并返回了域程序集对象(就像您描述的那样).当然,这需要从基础设施到域的参考.
为了将它们组合在一起,"WebApp"程序集("Web"程序集)引用了域和基础结构程序集,并使用IoC容器来解析所有应用程序依赖项.当请求进入WebApp时,它将解析相应的"域"合同以提供启动IoC解析调用链的请求.在注册基础结构实现之外,WebApp程序集并不关心基础结构程序集是否存在.
这个应用程序运行良好的原因是它实现了您在问题中所述的目标:
这为您的业务领域提供了大量可测试性,并为前端与您的域的接口提供了很大的灵活性.事实上,这种灵活性是什么使得它如此测试.这种灵活性也有其他好处.例如,如果您的业务域是隔离的,那么如果您想部署和运行客户端,则可以轻松编写一个新的CLI或WPF前端,这些前端连接到文件系统后端,而不会更改一小块业务域代码在机器上本地.
虽然这个例子看起来有些牵强附会,但就我上面提到的应用程序而言,开发团队正在考虑构建一个Web Services前端,以补充已经存在的MVC网站前端.这对于该团队来说只是一个现实的可能性,因为他们像您所描述的那样设置了该应用程
你说得很有道理，你的推理也很合理。Web层同时引用Core和Data，是一种很常见、合理、务实的设计。您没有创建任何循环引用并保持它非常干净。