MVC设计模型

 

      在web早期的开发中，通常采用的都是model1。Model1设计模式中，主要分为两层，视图层和模型层。那么，项目中的业务流程该如何处理呢？实际上，model1模式中jsp就充当了这个角色，也就是说一切的业务逻辑都是由jsp来处理的，通常是通过jsp直接调用模型来处理相关的业务，model1是以jsp为中心的。举个例子，比如我们用model1模式开发了一个网站，该网站可以注册会员，那么当我们在注册页面中点击提交时，我们在页面中输入的数据就直接提交给一个jsp对象了，然后由该jsp对象直接调用dao类对象，往数据库中插入一条注册记录，实际上，该jsp对象可以直接就是展示注册页面给我们的jsp。好了，看完例子，我们是否会觉得model1的设计模式在逻辑上比较混乱呢？我想答案是肯定的，要不然也不会引出现在正流行的mvc设计模式了。然而，model1也还是有其自己的优点的。那就是，对于一个小项目而言，采用model1模式来开发，开发效率往往会更高。但是，model1开发模式所带来的问题是，使用该模式开发的项目难以扩展，难以维护，代码重用率也相当低。

       由于现在人对软件质量的要求越来越高，软件项目的规模也越来越大，所以model1设计模式绝对不再适用于现在的软件开发。现在的软件开发是以工程的思想进行的，因此，model2，也就是mvc设计模式，自然而然就受到了人们的追捧了。简单的说，mvc模型就是Model—View—Control结构。 Model（模型），是业务逻辑层。用于封装业务逻辑和数据模型。View（视图）是表示层。就是与用户实现交互的页面，通常实现数据的输入和输出的功能。Controller（控制器）是控制层。起到控制整个业务流程的作用，实现View层跟Model层的协同工作。那么mvc组件类型的关系和功能是怎样的呢？

 

 

         MVC结构提供了一种按功能对各种对象进行分割的方法，其目的是为了将各对象间的耦合程度减至最小。MVC结构本来是为了将传统的输入（input）、处理（processing）、输出（output）任务运用到图形化用户交互模型中而设计的。但是，将这些概念运用于基于Web的企业级多层应用领域也是很适合的。
        在MVC结构中，模型（Model）代表应用程序的数据（data）和用于控制访问和修改这些数据的业务逻辑（business rule）。
        当模型发生改变时，它会通知视图（View），并且为视图提供查询模型相关状态的能力。同时，它也为控制器（Controller）提供访问封装在模型内部的应用程序功能的能力。
        一个视图（View）用来组织模型的内容。它从模型那里获得数据并指定这些数据如何表现。当模型变化时，视负责维持数据表现的一致性。视图同时将用户要求告知控制器（Controller）。
        控制器（Controller）定义了应用程序的行为；它负责对来自视图的用户要求进行解释，并把这些要求映射成相应的行为，这些行为由模型负责实现。在独立运行的GUI客户端，用户要求可能是一些鼠标单击或是菜单选择操作。在一个Web应用程序中，它们的表现形式可能是一些来自客户端的GET或POST的HTTP请求。模型所实现的行为包括处理业务和修改模型的状态。根据用户要求和模型行为的结果，控制器选择一个视作为对用户请求的应答。通常一组相关功能集对应一个控制器 。
       视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XML、WML和Excel。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务逻辑的处理。业务逻辑的处理由模型(Model)完成。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。
       控制器(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。
       模型(Model)：就是业务流程/状态的处理以及数据模型的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。模型的设计可以说是MVC最主要的核心。

各层的功能可以概括为：
视图：
        1.显示格式化后的数据
        2.向控制器发出请求
控制器：
        1.响应视图的请求，调用相应的模型
        2. 根据用户请求和模型响应结果,选择合适的视图
模型：
        提供纯净数据

那么mvc设计模式有那些优点呢？
        1. 首先，最重要的一点是多个视图能共享一个模型。由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用，无论你的用户想要Flash界面或是 WAP 界面；用一个模型就能处理它们。由于已经将数据和业务逻辑从表示层分开，所以你可以最大化的重用你的代码。
        2. 因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务逻辑。如果你想把你的数据库从MySQL移植到Oracle，只需改变你的模型即可。一旦你正确的实现了模型，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松偶合的组件。
        3. 在MVC模式中，由于按层把系统开，那么就能更好的实现开发中的分工。网页设计人员可以进行视图部分的开发，对业务熟悉的开发人员可开发业务模型，而其它开发人员可开发控制层。 同时，在项目维护中，因为结构清晰，非常利用维护工作。
        4. MVC更符合软件工程化管理的精神。不同的层各司其职，每一层的组件具有相同的特征，有利于通过工程化和工具化产生管理程序代码。

mvc设计模式也有它本身的不足：
        1. MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。
你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序到来了一定的困难。
        2. 增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
        3. 视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
        4. 视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

        总之，MVC设计模式是一个很好创建软件的途径，它所提倡的一些原则，像数据和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的组件，你可能需要重新思考你的程序，尤其是程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。