构造器注入(Constructor Injection)
应用服务的实现,使用了构造器注入以获得所需对象的实例。例如CustomerManagementService类的构造函数接收两个参数:ICustomerRepository的实例,以及ICountryRepository的实例。当分布式服务组件使用IoCFactory.Instance.CurrentContainer.Resolve方法来获得ICustomerManagementService的具体实现时,IoC容器会根据配置信息来自动解析ICustomerRepository和ICountryRepository的依赖,从而在创建ICustomerManagementService对象的时候,将解析出来的repository实体传给CustomerManagementService的构造函数。我们可以从Infrastructure.CrossCutting.IoC.csproj项目的IoCUnityContainer类的ConfigureRootContainer中找到这种依赖关系的设置代码。有关NLayerApp中IoC容器的实现请参考《container.RegisterType数据传输对象(DTO)
在NLayerApp中,使用领域实体(Domain Entities)作为数据传输对象(DTO),同时也实现了一些用于特定用途的DTO,比如DistributedServices.MainModule.csproj项目里的PagedCriteria。在应用服务上将领域实体作为数据传输对象来处理,也就决定了在其更高层:分布式服务中,也必须使用领域实体作为DTO。原因很简单:分布式服务并没有将DTO转换为领域实体的职责,这是应用层的任务。另一方面,原本WCF会在客户端产生Contracts的代理类型的时候,会屏蔽掉领域实体作为DTO所带来的弊端,但貌似NLayerApp的客户端程序是直接引用的领域实体来进行数据交换的,从DDD的角度讲,这种设计是有问题的。当然也应该具体情况具体分析。NLayerApp中,大多数View Model都能够与领域实体的结构相对应,并且直接将领域实体用作DTO在一定程度上降低了开发复杂度,提高了生产率。NLayerApp在其官方的资料中也提到过这个问题:The latter case is when we use DTOs (Data Transfer Objects) for remote communications between Tiers, where the domain model's internal entities would not flow to the presentation layer or any other point beyond the internal layers of the Service. DTO objects would be those provided to the presentation layer in a remote location.
If the implementation of the entities is strongly linked to a specific technology, it is contrary to the DDD Architecture recommendations because we are contaminating the entire architecture with a specific technology. However, we have the option of sending domain entities that are POCO (Plain Old CLR Objects), that is, serialized classes that are 100% custom code and do not depend _disibledevent=>DTO的设计需要面向客户端(包括客户端应用程序、与外部系统集成的Web Services等),客户端的View Model需要什么样的数据,就设计什么样的DTO。应用层负责收发DTO数据,并根据DTO数据访问领域模型中的实体,根据实体组装DTO。ORM解决的是Domain Model与关系型数据库之间的阻抗失衡,而DTO解决的是View Model与Domain Model之间的阻抗失衡
应用层服务对任务的协调职能
很多朋友无法理解应用层存在的意义,总觉得按照传统的三层架构就是数据访问层(DAL)、业务逻辑层(BLL)和表现层(Presentation)。NLayerApp的系统架构为我们展现了应用层的任务协调职能及其存在的必要性。例如BankingManagementService的PerformTransfer方法中,包含了位于基础结构层的分布式事务处理和位于Domain Model层的repository与UoW的操作。而整个PerformTransfer方法则将这些操作整合起来,以完成一个特定的应用任务:完成转账的功能。通常情况下,应用层的代码中会包含对其下各层组件的访问,因此,DDD的分层并不是严格型的(上层仅能依赖于其直接下层)。当然,如果你的应用程序并不存在需要多层协调才能完成特定任务的情况的话,应用层也可以省略。OK,今天就先讨论到这里,下一讲我将简要介绍一下NLayerApp中的分布式服务(Distributed Services)部分。
最新评论