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（请注意我有Phone实体和Email实体））组合到逻辑Manager类（如ContactsManager）中（注意我没有“Contact”实体类型）。使用ContactManager.GetPhones（）和ContactManager.GetEmail（）等方法

我想我想知道其他人如何组织和委派职责，无论他们是否有服务层，业务层，两者等等。具有ORM上下文参考的内容等等。

Answer 1

我倾向于在您关注的最后阶段做出您所概述的内容，并且在业务层将事情分组到管理层中，从业务角度来看更具逻辑意义。

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

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

听起来你已经知道自己想要做什么，所以我建议你做一些原型设计工作，看看它是如何运作的。：）

n层业务/服务层设计

1 个答案: