框架模式之MVC思考

做为web开发应用程序中应用最广的系统设计架构——MVC。从字面层面上很好理解，

M 就是数据层，负责数据逻辑处理；包括数据的存储，封装，通常做得也就无法是增、删、改、查这几个操作。而不同系统数据的存储方式可以是多样的，可以用数据库、文件、缓存各式各样可以存储数据的媒介。很多成熟的开源框架都把这一层封装起来，例如php语言的Thinkphp。这种好处是规范以及提高工作效率。但是在对数据库性能要求不高的项目中是没什么问题的，如果在复杂的项目或者对性能要求比较高的项目中，一个简单查询或者关联查询，可能不单单用到了一个数据库就解决问题了。这时候就需要对Model的设计要有比较合理已经优化的空间。数据复杂的程序当中，Model当中的各个模块操作如何关联？通常简单的模块设计是一个数据类型，相同属性的表放在一起，对其进行select、delete、update、insert；而如果此时用到关联的模块是否用分别select之后用程序逻辑来实现呢？作为编程人员来说，其实这是很糟糕的事情。如果从数据层能解决的事情就尽量在数据层解决，其原理是你用到的数据引擎很多是已经做了优化的。只要多数据库编程有些能力就可以用好它。从程序设计这一层的意义上就涉及到数据的设计。

V 是视图层，视图层既是可见层，包括用户设计界面，用户交互界面，软件和程序的输入和输出数据交互。这样设计的好处是可以灵活自由的扩展，使程序更加健硕。很多视图都用模板，控件实现。在成熟的语言开发中，View的设计对应逻辑是从控制层进行交互。视图的设计通常都是以界面为单位，在程序的生命周期中，正常的逻辑入口应该是从界面开始的，当然也不是所有的系统中都有view层，所以这种架构一般只适合图形界面交互的应用程序。

C 是控制层，控制层负责接受view得到的输入以及和mode的数据存储处理，这一层的逻辑处理最为复杂，一般安装功能模块划分，如果说控制层依赖于视图来设计，那么应该把视图上的所有显示和隐藏的功能对应的映射如何划分？在面向对象的程序设计里面讲究高内聚低耦合，而在面向接口编程中又把功能划分单一以及对应的职责，所以如果要很好的设计这一层的逻辑关系到整个项目的扩展和维护工作。

这种架构的优点在于层次划分明显，便于图形程序的架构。但是缺点也是视图和控制层的紧密联系