n层业务/服务层设计

Question

我试图重新评估我们的n层结构，很想得到根据您的经验提出了一些建议。这是我们典型的.NET n层（有时是n层）设计。

Project.UI 
Project.Services 
Project.Business 
Project.Model 
Project.DataAccess 

数据访问通常由Entity Framework 4和Repository类。我试图遵循Aggregate Root的概念，以避免拥有一个表格存储库，在我的经验中说起来容易。我倾向于在储存库和表格之间有〜70％的匹配。

模型通常由我Entity Framework 4实体的，我一直在使用自追踪EF实体成功。

业务是什么，我挣扎之最。我通常每Repository有一个Manager类。这个类将包含像.Add（）这样的方法，它将在转发到repository.Add（）之前执行业务验证。

服务，通常我只会实现这个如果事实上我期待建立一个基于Web服务的解决方案。这一层将负责封送DTO和实体之间的请求/响应。最重要的是提供更多的coarse grained接口。例如一个TradingService.SubmitTrade（），这实在是一个facade用于商业交易可能包括AccountManager.ValidateCash（），OrderManager.SubmitOrder（）等

参与讨论
我的业务层是非常实体以实体为中心，实际上它只是实体和存储库之间的粘合剂，两者之间进行了验证。我见过很多设计，其中服务层是对存储库的引用（实质上跳过“业务层”）。实质上，它与我的业务层具有相同的用途，但是它的确是有效的，但是它的责任（和命名）是一个更高层次，更粗糙的业务事务处理。使用上面的示例TradingService.submitTrade（）不会委托给任何业务经理类，它本身将查询必要的存储库，执行所有验证等。

我喜欢我的设计，因为我可以重用业务但是我讨厌这样一个事实：对于每个存储库，我都有一个匹配的业务层管理器，从而创建大量额外的工作。也许该解决方案是业务层级别的不同类型的分组？例如，将诸如PhoneManager和EmailManager（注意我拥有电话实体和电子邮件实体）的单独管理器类合并到ContactsManager等逻辑管理器类（请注意，我没有“联系人”实体类型）。使用诸如ContactManager.GetPhones（）和ContactManager.GetEmail（）等方法。

我想比其他任何我想知道其他人如何组织和委派职责，无论他们有服务层，业务层，两者等什么持有ORM上下文引用等

Answer 1

我倾向于做你概述了附近的您的问题结束，并在业务层组的东西到管理者，使从商业的角度来看更符合逻辑的意义。

例如使用联系人，我肯定不会有PhoneManager或EmailManager。 “ContactsManager”对我来说是一个更有用的组合，只有少了很多经理才能完成同样的事情。从商业角度来看，电话号码和电子邮件只是一小段联系人。仅仅因为他们拥有自己的表和实体并不意味着他们需要自己的经理。这并不意味着你不能重用它们。如果您需要在几个地方使用电子邮件地址进行工作，ContactsManager可以有相关的方法。

我们在我们的环境中倾向于使用的是数据库/实体层，然后是位于服务器上并处理业务规则和业务逻辑的业务层。该业务层通过WCF作为服务公开给客户端（或者至少与客户端相关的东西是）。

这听起来像你已经知道你想做什么，所以我会建议做一些原型工作，看看它是如何工作的。 :)