.Net之三层架构

引言

        通常意义上的三层架构是将真个业务应用划分为：界面层（UI层）、业务逻辑层（B层）、数据访问层（D层）。对于复杂的系统分层让结构清晰，便于开发人员对系统进行整体的理解、把握；而且便于维护，系统基本的架构可以通过工具自动生成代码。当数据库发生改变时，只用重新生成代码，改动业务逻辑层的部分代码即可。
三层架构分为：表现层（UI（User Interface））、业务逻辑层（BLL（Business Logic Layer））、数据访问层（DAL（Data Access Layer））再加上实体类库（Model）

DTO层与model层的区别

Model层是面向业务的，我们是通过业务来定义Model的。而DTO是面向界面UI的，是通过UI的需求来定义的。

    通过DTO我们实现了表现层与Model之间的解耦，表现层不引用Model。如果开发过程中我们的模型改变了，而界面没变，我们就只需要改Model而不需要去改表现层中的东西。

    需要了解的是，数据传输对象DTO本身并不是业务对象。数据传输对象是根据UI的需求进行设计的，而不 是根据领域对象进行设计的。比如，Customer领域对象可能会包含一些诸如FirstName, LastName, Email, Address等信息。但如果UI上不打算显示Address的信息，那么CustomerDTO中也无需包含这个 Address的数据
 

可以这样理解：Model是对数据表实体的映射；DTO是针对于前台页面的封装，可以是一个表或多表。如果Model字段可以直接满足前台页面需要，可以不用定义DTO

 DTO(data transfer object):数据传输对象，以前被称为值对象(VO,value object)，作用仅在于在应用程序的各个子系统间传输数据，在表现层展示。与POJO对应一个数据库实体不同，DTO并不对应一个实体，可能仅存储实体的部分属性或加入符合传输需求的其他的属性。
    DAO(data access object):数据访问对象。提供访问数据库的抽象接口，或者持久化机制，而不暴露数据库的内部详细信息。DAO提供从程序调用到持久层的匹配。

DTO即数据传输对象。之前不明白有些框架中为什么要专门定义DTO来绑定表现层中的数据，为什么不能直接用实体模型呢，有了DTO同时还要维护DTO与Model之间的映射关系，多麻烦。

摘两个比较有意义的段落。

表现层与应用层之间是通过数据传输对象（DTO）进行交互的，数据传输对象是没有行为的POCO对象，它 的目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递。为何不能直接将领域对象用于 数据传递？因为领域对象更注重领域，而DTO更注重数据。不仅如此，由于“富领域模型”的特点，这样 做会直接将领域对象的行为暴露给表现层。

需要了解的是，数据传输对象DTO本身并不是业务对象。数据传输对象是根据UI的需求进行设计的，而不 是根据领域对象进行设计的。比如，Customer领域对象可能会包含一些诸如FirstName, LastName, Email, Address等信息。但如果UI上不打算显示Address的信息，那么CustomerDTO中也无需包含这个 Address的数据

简单来说Model面向业务，我们是通过业务来定义Model的。而DTO是面向界面UI，是通过UI的需求来定义的。通过DTO我们实现了表现层与Model之间的解耦，表现层不引用Model，如果开发过程中我们的模型改变了，而界面没变，我们就只需要改Model而不需要去改表现层中的东西。

问题描述

我正在使用简单的3层体系结构。
在此，我使用DTO类在UI，BL和DL之间进行通信。
那么，层之间还有更好的通信方式吗？还是这是正确的方法？

推荐答案

DTO，数据传输对象，是分布层的概念，在传输数据时使用在您的消费者和您的服务之间。因此，如果您不发布任何服务，请下DTO。

要回答您的问题，还取决于您的应用程序有多复杂。如果简单，则只需使用CRUD操作，甚至可以使用 DataTable ， DataSet 进行通信。

否则，DDD中的域实体是各层之间的通信的核心对象：数据访问层，业务逻辑层和表示层。

基本上，应用程序中有一些不同类型的对象：

1. 
   
2. DTO，在您进行公共服务时使用，主要对象用于消费者之间的通信
   
3. 视图模型，表示层中的对象用于支持UI。
   
4. 域实体来自业务逻辑层，其中包含业务逻辑。 / li>

请注意以下术语：

1. 
   
2. 层：表示物理层，例如数据库服务器，Web服务器。
   
3. 层：表示逻辑层：表示层，业务逻辑层，数据访问层。