MVC设计模式与多层架构

MVC设计模式与多层架构

多层架构

就拿B/S开发说起。最初的ASP直接把数据库访问代码写在页面上。整个网站就是几个页面。数据访问、业务控制、界面显示全都在一个文件里。这种设计可以理解为一层架构。因为它没有分层的概念。在这样的开发模式下，同样的逻辑代码经常出现在多个地方。当有相似的功能需要实现时，直接拷贝代码到另一个地方，然后修改。如果遇到系统升级或业务规则发生变化，必须找遍整个系统并作调整。这样的设计不仅工作量大，而且不利于维护。往往一个程序员必须熟悉数据访问和业务规则，同时还得精通页面的编写，因为要写完一个功能就必须把这些内容全部写在页面上。JSP程序员在开发一个功能时会写两样东西jsp和JavaBean。JaveBean封装了数据访问和业务逻辑，jsp页面调然JavaBean的接口，然后将数据显示在页面上。这样如果有多个页面需要用到相同的业务规则只需调用同一个JavaBean封装好的接口即可。如果修改了业务规则直接修改JavaBean而不用到每个页面上去寻找相同的代码。同时也使得业务逻辑实现人员可以和界面开发人员分工合作。这种设计可以理解为两层架构（表现层、数据访问+业务逻辑）。随着编程技术的发展，人们发现不同的业务规则里可能会用到相同的数据。如果按照原来的设计方式同样存在许多重复的代码在JavaBean里。所以后来就将数据访问和业务逻辑再次细分。形成了表现层+业务逻辑层+数据访问层这种架构。当然，随着技术的发展和系统复杂程序的增加，一个系统还可能存在其它的“层”，如：权限验证层、对象缓存层等。

三层（多层）架构的出现，使得程序编写的代码得以重用，程序员之间可以更好地分工合作，程序架构更加清晰并易于维护。但三层（多层）架构并非适合于所有的项目开发。原先获取一个数据只需直接从数据库查询出来即可。用到了三层（多层）架构后还得先通过业务逻辑层，然后数据访问层才可以得到。原来一个类或一段代码就可以完成的操作变成了好几个类协作才能完成。如果项目规模并不大，采用这样的多层架构就像杀鸡用牛刀一样反而不顺手了。所以，多层架构适用于需要协同开发且具有一定规模或业务较复杂的系统。同时由于分了多层，一个接口的变化可能会引起多层接口的修改。

MVC设计模式

MVC是一种非常经典的设计模式。它广泛应用于各种语言和各种类型的应用中。MVC的思想是将“显示”（View）、“数据”(Model)和“控制”(Control)分开。MVC (Model_view_controller)” 模型-视图-控制器”。View部分负责向用户展示数据和接收用户输入Control负责接收View传来的输入并执行相应的业务逻辑获得执行结果，然后再调用View将结果向用户呈现。Model是输入和输出的数据载体。MVC将显示和控制分开，使得View的变化不会影响到Control的修改，同时同样的数据可能会提交到不同的View进行显示。

MVC多层架构

对于大多数朋友会认为三层架构就是MVC的原因，我想可能是因为MVC和三层架构都是分三个部分吧。多层架构的思想是低层为上层服务，上层调用低层时根本不用关心具体实现（所以在多层架构中通常是通过接口进行调用，而非具体的实现对象）。MVC则是分工合作，相互协调。另外还有点需要说明一下:

MVC中的Model和三层架构中用到的Model在概念上并非同一对象(虽然在大多数情况下是同样的类在担当这个职责)。MVC中的Model是值对象(Value Object 简称VO)，其职责是封装需要传递到View进行显示的数据。三层架构中的Model是业务对象(Business Object简称BO)，其职责是在处理业务逻辑时进行数据传递。在有些复杂的系统中还有持久对象（Persistant Object简称PO）。

后记

不能将三层架构和MVC混为一谈，多层架构和MVC都是前人的经验总结。好好利用多层架构和MVC可以开发出健壮、易于扩展的系统。而软件开发人员必须深入理解这些设计模式的精髓方能灵活应用，否则将会深受其害，在开发中处处受制。

文章引用来自http://www.cnblogs.com/leo_gu/archive/2010/04/28/1723397.html