blu*_*blu 0 architecture asp.net-mvc model linq-to-sql
我正在寻找关于如何将业务规则合并到asp.net mvc应用程序以及它们与模型的关系的一些指导.
首先是一个小背景,所以我们知道这个问题的解决方案是什么类型.在工作中,我们使用WinForms,MVP,BusinessObjects,DataAccessObjects和DataTransferObjects.层的边界使用DTO将参数发送到方法和返回类型,或返回List类型.
现在我们正在添加一个Facade层来将DTO转换为域对象以供UI使用,因为架构师不喜欢在PresentationLayer中使用DTO当前是如何工作的.除了实用与否之外,我在理论上对这一切感到很自在.
我正在建立一个有趣的网站,但考虑到它可以说它提供与SO相同的流量,就像我听到的每月60,000次点击.我对控制器和视图的机制以及模型如何与两者集成感到满意.
我使用NerdDinner作为构建站点的示例,我遵循示例中的Repository模式实现.我没有得到的是如何将业务对象合并到一起.
我听说人们谈论LINQ作为DataAccessLayer/DataAccessObjects.如果我通过业务对象强制我的所有请求,因为我已经习惯了,我已经介绍了一些奇怪的依赖项.我的UI和我的BO都必须知道我的DAO.
有意义的是将LINQ类用作真正的DAO层,将其隐藏在BO后面,并在POCO和LINQ对象之间进行BO转换.
我唯一担心的是将我的UI绑定到LINQ类,并不需要所有额外的工作,我很满意NerdDinner中的轻量级方法.
所以我本质上是在控制器中实例化的Repository,它接受并返回LINQ对象.我的业务对象有静态方法,只需要LINQ类并执行一些计算,比如应用某个州税%或w/e.
由于很多这些计算必须在存储库的结果中完成,我正在考虑将它们组合到一个中心区域,如外观层,但是它只是转换数据而不转换为其他对象集(DomainObjects) < - > DTOs).
我应该这样做,还是应该说这些业务方法确实是我的模型的一部分,并且它们应该在返回对象的存储库方法中？
从设计的角度来看,我会像这样设计它.当然,命名只是为了这篇文章的目的,你不必命名你的DAL和BLL ..Repository和..Service.
拥有应该发生数据访问/查询的存储库(或者一个).它理想情况下应该只包含查询(编译或不编译).我个人拥有每种数据类型的存储库,以帮助保持查询分离.
下一层应该是您喜欢称为服务的业务层.这些类负责所有关于验证的逻辑,准备步骤以及为使服务的消费者获得所需信息而需要完成的任何其他操作.与ASP.NET MVC应用程序一样,我有我的服务返回视图模型,然后直接传递到强类型视图.通过我的服务,我通常将它们逻辑分组在一起而不是每种数据类型.
这是一个很棒的设计,因为它可以使您的数据访问代码和表示代码保持良好和精简,并且大多数可能出错的逻辑都在您的服务(或业务)层中.
| 归档时间： |
|
| 查看次数： |
2370 次 |
| 最近记录： |