MVC架构理解

     在学习Web程序设计时，总是会遇到MVC这种架构，它是一种将程序分为至少包含M(模型)、V(视图)、C(控制器)三个层次结构的设计方法。MVC很早就出现了，它是人们关于程序设计的经验的总结，能够在程序设计时做到关注分离，即不同的模块只关注应用的一个部分，它们之间通过接口进行松散耦合，使得我们可以很方便的进行模块化程序设计。
    模型(M)，是整个架构中最重要的部分，因为它代表着应用的域环境，我觉得它应该是程序真正关心并需要实现的业务逻辑部分。在设计开始时，总是要进行需求分析和提炼，这时候就会出现很多业务域的对象、过程、关系等，这些就是模型的初始状态。在域模型中，我们只关心与业务逻辑有关的属性和操作，并定义与之有关的对象和接口，其他非相关操作，如数据持久化等，都通过接口调用其他模块的实现完成。这里以一个商店的例子开始，第一个相关的域对象肯定是商品，因此需要定义一个域对象Product:
    public class Product
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Description { get; set; }
        public decimal Price { get; set; }
    }
    为了能够操作这个Product对象，需要定义与之相关的接口，描述出相关的业务逻辑，如取出所有商品、删除商品等：
    public interface IProduct
    {
        IList<Product> GetProducts(int count);
        void RemoveProduct(int productID);
    }
    这里之所以定义接口而非对象，是因为它将与其他模块进行交互，而它的业务逻辑可能有不同的实现，因此采用接口与实现分离的方法。
    控制器(C)，是整个架构中的枢纽，它负责从视图接收请求，并调用模型获取响应，之后返回新的视图给用户。控制器绝不应该处理有关业务逻辑的问题，它分析用户的请求，组合不同的模块，如用户需要显示商品列表时，它会生成IProduct的实例，并告诉它从哪(持久化接口)可以读到商品数据。通常，模型中只通过接口操作数据的读写，不关心何种实现，这时，就需要控制器去生成相关的数据操作接口(如数据库)实例并传给模型实例。从模型中获取数据后，控制器也不会执行与视图显示有关的操作，它应该简单的组织一下数据，如排序、选择、排除等，然后将数据直接传递给视图模块。定义控制器如下：
    public interface IProductController
    {
        // 按页读取数据
        IList<Product> GetProducts(int currentPage, int pageSize);
        // 搜索数据
        IList<Product> SearchProducts(string keyword);
    }
    控制器接口中的方法可能跟模型中导出的方法相同，但是它们的作用不一样的，服务的对象也是不同的。模型中可能只是简单的读取数据，也可能需要进行业务逻辑处理，而控制器则是在模型返回的业务数据的基础选择满足用户需求的数据，或者什么都不做。
    视图(V)，是整个架构中唯一和用户进行交互的部分，接收用户事件，显示相关数据。通过MVC将应用进行划分后，视图只通过接口和控制器进行交互，没有任何业务逻辑、数据存取逻辑，因此UI人员可以独立、高效地开发出满足用户需求的UI，而不用担心变化导致的更改。
    为了更好的实现MVC架构，还需要一个数据访问层，它屏蔽控制层、模型层对底层数据操作的变化修改。可能还会用到其他相关的设计模式，如使用工厂模式创建各个接口的具体实现，从而使需要接口的地方不需要关心如何创建实例，以及使用依赖注入模式，将模型对数据访问层的依赖性由模型的构造函数传入，即在创建模型实例时指定数据访问接口的实现。

本文出自 “Jsl_mes” 博客，请务必保留此出处http://jslmes.blog.51cto.com/5008224/1277039