在一个理想的层级项目中，展现层是不能直接访问领域对象的，那么展现层如何获取到自己需要的数据呢？也就是今天的主角-Application层，它的职责就是为展现层服务，它通过仓储获取到相应的数据，然后将数据以Dto的形式传给展现层，负责展示。
那么问题来了：1.什么是Dto？2.Dto的好处是什么？
一.Dto
Dto (Data Transfer Object):数据转换对象，也就是用来传递数据用的。
Dto的好处：
1.在EF的CodeFirst的Model中，我们经常会使用导航属性，但是使用导航属性，带来方便的同时，经常会遇到将数据序列化的问题，也就是对象循环序列化的死循环中。这就是直接使用Model作为展现层数据传输媒介带来的问题。所以我们可以使用Dto来避免。
2.Model中的数据就是数据库中的具体的字段，然而我们可能只是使用其中的很少一部分的数据用于前台的展示，所以使用Dto可以根据我们自己的需要减少传递的数据量，起到一定的保密性。
3.ABP框架中已经实现了一些现有的Dto，可以方便我们的开发，同时支持Dto的验证，提高数据的安全性。
4.说到底，Dto最大的好处就是灵活，可以根据自己的需要灵活的扩展，不影响与数据库的操作。起到了一定的解耦分离的作用。
在ABP框架中提供了很多方便我们开发的Dto,关于Dto的数据验证，将在接下来的“电影票系统”的增删改中具体的实践，今天主要是针对的“查”，先展现出来看看再说。
二 .Application层的具体操作
我们自己的应用服务层的代码创建在哪里呢，当然是ABP模板中为我们创建的Application中啊，嘿嘿
上面就是ABP模板为我们自动创建的Configuratrion功能的相关文件，我们按照上面的模式，创建出我们自己的Dto文件夹，AppService 和接口。需要的注意，这里我们自己定义的服务层的接口和实现类的后缀名都是以AppService接口为结尾的，这是ABP框架中的约定，至于为什么要这样，肯定是ABP中有很多的操作都是按照这个约定实现的，所以我们只需要按照约定办事就好了。
1.首先创建出我的目录结构
2. 前面的说过，一定要按照约定，以AppService命名结尾
Service
IService
Dto
Dto这边需要注意两点：
1.一定要定义Mapper的映射规则，此处采用的是特性标签的方式定义映射规则。
2.前面已经说过ABP中提供了很多的现成的Dto可以简化我们的操作，上面的EntityDto里面定义了一个Id属性，同时EntityDto还提供了泛型的支持，满足对不同类型的Id的支持。
至于展现层，这里我直接模仿代码模板中的样式，稍微修改一下（先偷个懒）
这个父类继承了AbpController，AbpController重写了MVC的Controller的一些东西，同时提供了一些常用的属性注入，比如AbpSession等
从上面的代码中可以看出，我们的控制器也是支持注入的，而且也是临时的，及时销毁的.
接下来我们就跑一下看看，能不能展示出来呢
我们定义的Service在Controller中没有注入进来，为什么没有注入进来呢？喜闻乐见，这就是没有按照约定办事的结果。。。。。。这里我们对MovieTicketAppService的命名重新更正。
再次运行一下，哈哈哈，出来了！
三.应用服务层的三个注意点
1.一定要实现接口IApplicationService，一定要按照约定来命名自己的Service，这是确保可以依赖注入的关键。
2.ApplicationService也是采用的UnitOfWork的模式，这个跟仓储那边是类似的。就是在一个服务方法中，共用一个数据库连接，共用一个事务，当方法结束时，提交事务同时关闭数据库的连接。
3.应用服务层注入的实例也是临时性的，这个在上面的代码中可以看出，IApplicationService继承自ITransientDenpency。
其实还有一个问题没有详细的介绍，既然我们有Dto用来为展现层提供数据，那么我们的Model是如何转换为Dto的呢？哈哈哈，这个简单，不就是属性赋值嘛，我一个个给Dto赋值。。。嗯，没毛病。我上面使用了一种简单的方法，那就是AutoMapper，自动实现映射，这个将在下一篇稍微研究一下。