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

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

Answer 1

我倾向于按照您在关注点结束时概述的方式进行操作，并在业务层将事物分组到管理器中，从业务角度来看，这些管理器更具有逻辑意义。

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

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

听起来您已经知道自己想做什么，所以我建议对其进行一些原型设计工作，看看它如何适合您。:)