.NET MVC与三层架构
二者都是架构模式，并且也有一定的共存度，在实际开发中，严格区分意义不大。
基于最近涉及到这部分知识就在复习下，编程过程中，基础概念更重要，而不是技术。
1.三层架构:即UI（表示层），BLL（业务逻辑层），DAL(数据访问层)
UI(表现层):主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。
BLL:(业务逻辑层):UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含：验证、计算、业务规则等等。
DAL:(数据访问层):与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给
业务层，同时将业务层处理的数据保存到数据库。
（当然这些操作都是基于UI层的。用户的需求反映给界面（UI），UI反映给BLL，
BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户）
其实，真正使用过三层架构的都知道，三者之间是通过Entity传递数据的，Entity贯穿三层，将三者连接起来，
同时也实现了对数据实体的封装，取代了个层之间多变量的数据传递(数据交流)，大大的简化了数据交流，
也降低了数据发生错误的概率。（Entity其实就是对数据库表实体的封装），Entity与三层之间的依赖关系
2.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动词等等，这样有利于项目的后期开发与维护，
以防止因人员流动而使项目无其他人愿意接手。