我正在寻找关于如何将业务规则合并到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＆lt; - ＆gt; DTOs）。
我应该这样做，还是应该说这些业务方法确实是我的模型的一部分，并且它们应该在返回对象的存储库方法中？
答案 0 :(得分：8)
从设计的角度来看，我会像这样设计它。当然命名只是为了这篇文章的目的，你不必命名你的DAL和BLL ..Repository和..Service。
拥有应在其中进行数据访问/查询的存储库（或其中一个）。它理想情况下应该只包含查询（编译或不编译）。我个人拥有每种数据类型的存储库，以帮助保持查询分离。
下一层应该是您喜欢称为服务的业务层。这些类负责所有关于验证的逻辑，准备步骤以及为使服务的消费者获得所需信息而需要完成的任何其他操作。与ASP.NET MVC应用程序一样，我有我的服务返回视图模型，然后直接传递到强类型视图。通过我的服务，我通常将它们逻辑地组合在一起，而不是每种数据类型。
这是一个很棒的设计，因为它可以使您的数据访问代码和表示代码保持良好和精简，并且大多数可能出错的逻辑都在您的服务（或业务）层中。