ASP.NET没有魔法——ASP.NET MVC & 分层

　　上一篇文章简要说明了MVC所代表的含义并提供了详细的项目及其控制器、视图等内容的创建步骤,最终完成了一个简单ASP.NET MVC程序。
　　注：MVC与ASP.NET MVC不相等，MVC是一种开发模式，而ASP.NET MVC是MVC这种模式的其中一种实现方式，本文中提到的MVC如果没有特指，那么均表示ASP.NET MVC。
　　本文将从ASP.NET的M-V-C到底代表什么？如何编写对应的代码？来讨论如何使用ASP.NET MVC开发应用程序。
　　○ ASP.NET MVC与分层
　　○ ASP.NET MVC中的M代表什么
　　○ ASP.NET MVC的V和C是如何交互的
　　○ ASP.NET MVC中的C应该如何处理业务逻辑
　　○ 如何使用ASP.NET MVC

ASP.NET MVC与分层

　　什么是分层？

　　在了解分层之前，先了解一下层次的概念，层次是指系统在结构或功能方面的等级秩序。具有多样性，可按物质的质量、能量、运动状态、空间尺度、时间顺序、组织化程度等多种标准划分。不同层次具有不同的性质和特征，既有共同的规律，又各有特殊规律。（来自百度百科）

　　所以分层实际上是根据一定的标准和规律，将一个整体划分为多个层次，保证每一个层次中的内容都有共同的性质和特征，便于针对每一个层次进行维护管理。

　　代码分层：

　　代码分层就是将代码根据其功能特性将代码分而治之，代码分层一般分为三层（所以也被称为三层架构），分别是UI层、业务逻辑层和数据层，分层架构主要是把整个系统的数据存储、业务逻辑、UI实现进行关注点分离：
　　○数据层：关注数据是如何存储的不需要业务逻辑来处理，只需要调用相应接口就可以完成数据的获取、存储等功能。
　　○业务层：把业务区分出来可以更好的专注于业务逻辑的实现，对于一些业务逻辑较为复杂的系统可以使用领域驱动(DDD)的方法去实现。另外业务逻辑可以被重用，一个常见的例子就是MVC以及Web API，MVC用于Web端应用开发，Web API还可以用于为其它客户端或者是提供第三方应用使用，所以业务逻辑的实现不能在UI层，否则就回出现MVC的Controller中存在一份代码，而Web API的Controller中也存在相同的一份代码，以致于代码难以维护。
　　○UI层：需要做的就只有用户界面的设计，设计师只需要去关心如何将需要表达的内容完美的表达给用户并提高用户体验即可。　

　　另外分层架构的“层”其实应该是根据业务特性、系统复杂度等因素来拆分的，分层可以让适合的人做适合的事情，并且设计模式中的“依赖倒置”原则定义模块直接要依赖抽象而不是实现，只要定义出抽象(接口)那么多个团队即可同时对不同的“层”进行开发。

　　注：以上的分层架构特指服务端分层架构，像移动应用甚至一些单页应用也会特意的进行分层以享受分层带来的代码管理的便利。

　　ASP.NET MVC是什么？

　　在上一篇文章中介绍了ASP.NET MVC以及MVC分别代表的意义。从意义上看起来MVC的概念和三层架构的概念很相似，它们分别都对应了UI、业务逻辑和数据。但是它们有着很大的区别，MVC的View、Controller、Model的作用是处理UI显示、操作和数据交换。换句话说ASP.NET MVC在三层架构中仅仅是UI层的一种实现。

ASP.NET MVC中的M代表什么　　

　　M代表数据模型，但是应用程序中是存在多种数据模型的，比如与数据库一一对应的数据模型、用于显示的数据模型，ASP.NET MVC中很容易混用这两种模型，举个例子，用户信息除了用户特征还会包含用于登陆系统的密码等信息。对用户信息修改时除了修改特征还会修改密码等，但是在显示时就肯定不会把密码显示出来。还有一种情况就是一个列表页面，它不仅仅显示记录条目，还会显示分页信息，但是分页信息是不会存储到数据库中的，所以这两种模型是有明显区别的。　　

　　ASP.NET MVC在分层架构中被定位为UI的实现，那么这里的M应该被看作用于显示的数据模型。一些人也把它称为View Model，但是这个View Model与MVVM模式下的View Model有本质的区别，这里的View Model是用于显示的数据模型。

ASP.NET MVC的V和C是如何交互的

　　根据之前的分析MVC的Model是用来展示的数据，所以理所应当的Controller应该生成一个Model交付给View来渲染。相反的，在通过Web页面提交一些数据时，这些数据来自View，那么View也应该提供一个Model交给Controller来执行相应的业务，它们的关系如下：

ASP.NET MVC中的C应该如何处理业务逻辑

　　Controller用于处理来自客户端的请求，然后给出响应。而这个处理的过程就对应了实际的业务逻辑，而MVC又处于业务逻辑层之上，所以Controller唯一能做的就是直接调用业务逻辑，这里的调用应该是顺序的，没有任何逻辑判断的，所有的处理均交付给逻辑层。
　　如何处理Controller和业务层的数据交换？视图模型还是实体模型(数据库模型)?
　　首先视图模型不可用，因为MVC在业务层之上，如果使用视图模型，那么下层依赖上层是违反依赖原则的。而且视图模型可能包含分页等信息，也不是业务层需要的。
　　其次可以用实体模型来交换，这个方案看上去可以，MVC以及业务都依赖一份实体模型。但是如果使用领域驱动来设计模型的时候怎么办？这时的“实体”包含了部分业务逻辑，而这部分的逻辑一般是不可以被UI层直接调用的。
　　根据以上的分析发现两种都存在不符合的应用场景，所以引入了DTO（Data Transfer Object）数据传输对象这个概念，关于这个概念后续在分析，现在的博客系统先使用实体模型来处理数据交换。

如何使用ASP.NET MVC

　　任何一个工具，不同的人可能会有不同的效果，对于软件开发来说除了完成功能性需求的开发，更重要的还有保证开发效率、软件质量、代码质量等非功能需求，以保证软件能够在适合的时间开发完成，代码可测试、可维护。但是不同的开发者使用工具习惯不一致，对于ASP.NET MVC来说，有的人可能习惯把Model当数据库模型和页面模型使用、把所有业务逻辑编写到Controller中、过多使用ViewBag等对象传输数据到View等。对于这些方法来说它仍然能够实现功能性需求，而且对于个人来说使用习惯的方法效率最高，但是对于一个团队来说这往往会造成很大的麻烦，每个人保持自己的风格，最后整个项目代码被改的面目全非，代码没有可读性、无法维护、无法测试等等。
　　所以在使用工具前必须统一规范。没有规矩不成方圆。ASP.NET MVC 在某些角度上对于MVC来说也是一种规范。
　　规范有好有坏，但无论好坏，只要存在规范，那么在修改规范时也会更容易，本系列文章会根据“博客系统”的进度来设定不同的规范，对于ASP.NET MVC的使用来说，应该有以下几点：
　　○ Controller只能顺序调用业务逻辑，不存在任何判断语句。
　　○ View在一般情况下只是用Controller传过来的Model对象，避免ViewBag等对象的使用。
　　○ Model只作为View和Controller之前的传输对象使用，与数据实体无关。

　　小结：
　　本章进一步的分析了MVC的概念，并在最后提出了规范，对于规范来说更多的指编码规范，比如命名规范、注释规范等等，这里的规范仅仅是对统一对ASP.NET MVC的使用方法，使得代码便于维护、测试，甚至后续使用代码生成器来生成代码也更加容易(关于代码规范等内容会在后续引入更多介绍)。

本文连接：http://www.cnblogs.com/selimsong/p/7646445.html

ASP.NET没有魔法——目录