N层业务/服务层设计

Question

我试图重新评估我们的n层架构，并希望根据您的经验获得一些建议。下面是我们典型的.NET n层(有时是n层)设计。

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

DataAccess通常由Entity Framework 4和Repository类组成。我试图遵循Aggregate Root的概念，以避免表的存储库，在我的经验中，说起来容易做起来难。我倾向于在存储库和表之间有70%的匹配。

模型通常由我的Entity Framework 4实体组成，我一直在成功地使用自跟踪EF实体.

生意是我最难对付的。对于每个Manager，我通常都有一个Repository类。该类将包含像.Add()这样的方法，这些方法将在转发到repository.Add()之前执行业务验证。

服务，通常我只会实现这一点，事实上，我希望创建一个基于web服务的解决方案。这一层的任务是在DTO和实体之间封送请求/响应。最重要的是提供了更多的coarse grained接口。例如，TradingService.SubmitTrade()，它实际上是一个业务事务的facade，其中可能包括AccountManager.ValidateCash()、OrderManager.SubmitOrder()等。

关注

我的业务层非常以实体为中心，实际上它只是实体和存储库之间的粘合剂，在两者之间进行验证。我看到了许多设计，其中服务层是存储库的引用(本质上跳过了“业务层”)。本质上，它与我的业务层具有相同的目的，但是它的职责(和命名)是一个更高级别、更粗粒度的业务事务。使用上面的示例，TradingService.submitTrade()将不会委托给任何业务经理类，它本身将查询所需的存储库，执行所有验证等。

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

我最想知道的是，其他人是如何组织和委派职责的，他们是否拥有服务层、业务层，等等。

Answer 1

我倾向于做你所关心的事情接近尾声的事情，在业务层，把事情分成从商业角度看更合乎逻辑的管理者。

例如，使用联系人，我肯定不会有一个PhoneManager或EmailManager。对我来说，"ContactsManager“是一个更有用的组织，它只在需要处理的经理少得多的情况下完成了几乎相同的事情。从商业角度来看，电话号码和电子邮件只是联系中的一小部分而已。仅仅因为他们有自己的表和实体并不意味着他们需要自己的经理。这并不意味着你不能重用它们。如果您需要在多个地方处理电子邮件地址，ContactsManager可以有相关的方法。

我们在环境中通常拥有的是数据库/实体层，然后是位于服务器上并处理业务规则和业务逻辑的业务层。通过WCF将该业务层作为服务公开给客户端(或者至少是与客户相关的内容)。

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