标签：
初始AutoMapper是在做成绩管理系统1.0的时候，那个时候因为系统采用了WCF+MVC+easyUI+EF的框架，那么我们在实现B层与WCF层之间的实体转换的时候就需要借助于某种方法（用纯代码实现）或者某种工具实现，我采取的是后者，因为每当遇到一个问题的时候，我总是觉得有比写纯代码更加简洁的方法。
那个时候只是上网查个例子就用，别的也没有想那么多。直到今天我的一个组内的伙伴让我调试的一个错误，我才真正意识到自己的是需要深入研究的。
初接手一个项目的时候，对于框架的以及业务的分析不是那么的清晰的条件下，大多数的人采用的是按实体划分而不是业务划分，估计就有人想省事，那就是采用把Model层的各个实体直接定义到数据契约或者我们说的提供给ui供显示的使用的viewModel,但是这样的结果出现偶然性，如果没有主外键的关系或者其它的关系复杂的方法，那么直接引入Automapper什么时候估计也不会报错，但是如果你的有复杂的主外键关系或者其它的一些复杂的方法，那么直接引入而不加配置的话，可能会出现很多的错误，比如出现“miss type map configuration or unsurported”等等。
此时经过查找将供UI显示的实体中的显示下面的存在复杂的主外键关系，注释掉后发现了，困扰的问题得以解决了。下面我们来认识一下Automapper吧。
在学习EF的时候我们知道了ORM（Object Relational Mapping）映射，是一种对象关系的映射，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。
而Automapper是一种实体转换关系的模型，AutoMapper是一个.NET的对象映射工具。主要作用是进行领域对象与贫血模型（DTO）之间的转换、数据库查询结果映射至实体对象。
数据传输对象（DTO)(DataTransfer Object)，是一种设计模式之间传输数据的软件应用系统。数据传输目标往往是数据访问对象从而从数据库中检索数据。数据传输对象与数据交互对象或数据访问对象之间的差异是一个以不具有任何行为除了存储和检索的数据（访问和存取器）。
引用别人的话说“表现层与应用层之间是通过数据传输对象（DTO）进行交互的，数据传输对象是没有行为的POCO（Plain Old CLR Object）对象，它的目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递。为何不能直接将领域对象用于数据传递？因为领域对象更注重领域，而DTO更注重数据。不仅如此，由于“富领域模型”的特点，这样做会直接将领域对象的行为暴露给表现层。
需要了解的是，数据传输对象DTO本身并不是业务对象。数据传输对象是根据UI的需求进行设计的，而不是根据领域对象进行设计的。比如，Customer领域对象可能会包含一些诸如FirstName, LastName, Email, Address等信息。但如果UI上不打算显示Address的信息，那么CustomerDTO中也无需包含这个 Address的数据”。
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
领域模型就是面向对象的，面向对象的一个很重要的点就是：“把事情交给最适合的类去做”，即：“你得在一个个领域类之间跳转，才能找出他们如何交互”。在我们的系统中Model（EF中的实体）就是领域模型对象。领域对象主要是面对业务的，我们是通过业务来定义Model的。
这个网上的资料很丰富，大家可以上网查找，对于一件事情，别人告诉你有这个事情，剩下的事情就是自己去学，给大家推荐一个博客
http://www.cnblogs.com/smileberry/p/3838143.html。
我们定义的领域模型对象例如Model面向业务，而DTO（在我们的系统中是数据契约或者说是viewModel是供ui使用的）是面向界面UI，所以我们应该根据UI的需求来定义。利用DTO可以使表现层与Model解耦解除，表现层（也就是显示的界面）不需要引用Model，这样的好处是即使我们的模型或者model发生改变，而界面无需改变的情况下，我们可以直接修改model而无需更改界面的显示，这样是实现了解耦合。
标签：
原文地址：http://blog.csdn.net/u010955843/article/details/45337647
