ASP.NET MVC Model＆Business Objects

Question

我正在寻找一些关于如何将业务规则合并到一个asp.net mvc应用程序以及它们如何与模型相关的指导。

首先有一点背景，所以我们知道什么样的解决方案是相对于这个问题。在工作中，我们使用WinForms，MVP，BusinessObjects，DataAccessObjects和DataTransferObjects。图层的边界使用DTO将参数发送给方法和返回类型，或者返回List类型。

眼下，我们正在把一个门面层到DTO的转换成域对象的UI一起工作，因为建筑师不喜欢如何在表示层使用DTO的工作目前。除了实用性或者不实际之外，我理论上对这一切都很满意。

我想提出一个有趣的网站，但考虑让说，它提供相同的通信量SO，像60000次命中最后一个月我听说了。我很熟悉控制器和视图的机制，以及模型如何与两者结合。

我使用的NerdDinner作为构建网站的样本，我按照示例中的存储库模式执行。我没有得到的是如何将业务对象结合到组合中。

我听到有人谈论LINQ作为DataAccessLayer/DataAccessObjects。如果我强制所有的请求通过业务对象，因为我习惯于引入一些奇怪的依赖关系。我的用户界面和我的BO都必须知道我的DAO。

会什么样的意义是使用LINQ类作为一个真正的DAO层，它隐藏在背后的BO和有BO POCO和LINQ对象之间的转换。

我唯一担心的有我很好的结合我的UI中的LINQ类，并不需要所有的额外的工作，我很高兴与薄轻量级的方法作为的NerdDinner。

所以我基本上是在获取和返回LINQ对象的控制器中实例化的存储库。我的业务对象有静态方法，只需要LINQ类和执行一些计算，比如说应用某个州税％或w/e。

由于很多这些计算必须跨存储库的结果完成，因此我正在考虑将它们组合到一个中心区域，比如一个外观层，但只是对数据进行转换而不转换为其他对象集（DomainObjects < - > DTO）。

我应该做的，或者我应该说这些业务方法真的是我的模型的一部分，他们应该在返回的对象存储库的方法呢？

Answer 1

从设计的角度来看，我会像这样设计它。当然命名只是为了这篇文章的目的，你不必命名你的DAL和BLL ..Repository和..Service。

有数据存取（或一个）您的数据访问/查询应该发生。理想情况下，它应该包含查询（编译或不）。我个人有一个每个数据类型的存储库，以帮助保持查询分离。

下一层应该是我喜欢称之为服务的业务层。这些类负责所有有关验证，准备步骤和其他任何需要完成的逻辑，以使服务的使用者获得所需的信息。与ASP.NET MVC应用程序一样，我有我的服务返回视图模型，然后直接将其传递到强类型视图。通过我的服务，我通常将它们逻辑地组合在一起，而不是每个数据类型。

这是一个很棒的设计，因为它可以让您的数据访问代码和表示代码变得更加简洁，并且大部分可能出错的逻辑都在您的服务（或业务）层中。