.NET MVC与三层架构

　　虽然接触了两者有一段时间了，但是有时还是会混淆概念，在此处不打算说明二者的区别，因为二者都是架构模式，并且也有一定的共存度，在实际开发中，严格区分意义不大。基于最近涉及到这部分知识就在复习下，编程过程中，基础概念更重要，而不是技术。

　　先看看，三层架构吧，即UI（表示层），BLL（业务逻辑层），DAL(数据访问层)：

　　　　UI(表现层):主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。

　　　　BLL:(业务逻辑层):UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含：验证、计算、业务规则等等。

　　　　DAL:(数据访问层):与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。（当然这些操作都是基于UI层的。用户的需求反映给界面（UI），UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户）

　　　　                                   

　　其实，真正使用过三层架构的都知道，三者之间是通过Entity传递数据的，Entity贯穿三层，将三者连接起来，同时也实现了对数据实体的封装，取代了个层之间多变量的数据传递(数据交流)，大大的简化了数据交流，也降低了数据发生错误的概率。（Entity其实就是对数据库表实体的封装），Entity与三层之间的依赖关系：

　　　　

　　再看MVC架构，即M（model 模型·）,V（view 视图）,C（controller 控制器）三个部分。在MVC架构中这三部分是必须的，但我们也可以根据项目的实际需求与实际情况还能再增加，比如实现Service层或Repository层等，我们可以自行扩展，大幅提高了开发时的灵活性。

　　　　Model（数据模型）:用于封装与应用程序在商业逻辑上相关的数据，以及对其数据操作的处理方法(数据库的访问操作，即增删改查；数据结构的定义；数据格式的验证)。Model并不依赖于View和Controller，也就是说Model并不需要知道它会如何被显示出来或如何被应用，只需要专注于自己该有的责任即可。Model中常见的技术有Entity Framework（即EF）、NHibernate、LINQ to SQL、Typed DataSet和ADO.NET等。

　　　　View（视图）:　页面显示或获取用户输入，View需要负责将Controller传过来的数据配合“显示逻辑”呈现给用户，此处虽然View需要Contorller传递数据，但是View并没有依赖某个Controller,任何Controller只要能提供View所需要的数据，View就可以根据显示逻辑将其显示出来，是一种松散的关联关系。

　　　　Controller（控制器）:属于一种结果协调者的角色，因为M-V-C三个部分没有直接的联系，View无法直接与Model沟通，即Model可以操作数据，View可以显示数据，因此，VIew显示的数据需由Controller从Model获取后提供给View。即Controller的角色位于用户接口层和商业逻辑层中间。

　　其中，MVC中最重要的特性是关注点分离和约定优于配置。关注点分离，简单地说就是“只注意需要注意的”，这样可以很好的解耦模块，各个单元的复杂度就相对降低，更容易开发，同时，也增强了程序的可维护性。约定优于配置，简单地说，就是开发过程中应该遵守的约定，如：Controller的文件名后面一定要以Controller结尾；View文件一定要放在VIews文件夹下；View的名称就是对应的Controller的Action名称；Web API的Action名称前面应该加上HTTP动词等等，这样有利于项目的后期开发与维护，以防止因人员流动而使项目无其他人愿意接手。