【J2EE】：MVC是框架？是设计模式？是架构？还是……

上篇博客简单聊了聊MVC模式，但是有一个很重要的问题我没有提到，那就是对MVC的定位，它是什么？

很多人都知道MVC，都知道就是把将数据和显示分离，知道Model—View—Controller，但是让你说MVC是什么东西，你可能不知如何回答。那么MVC到底是什么玩意呢？框架？设计模式？架构？都不是。

可以肯定的说（个人认为），MVC不是框架，不是设计模式，更不是架构，它仅仅是一种架构模式。它不描述系统架构，也不指定使用什么技术，仅仅是描述系统架构的一种模式，类似于AOP、IOC、ORM等等，具体的框架技术则是基于这些模式的一些实现而已，比如基于MVC模式的框架有著名的Struts、Spring MVC、JSF、Tapestry以及比较老的WebWork等等，基于ORM模式的框架有Hibernate、MyBatis、iBatis以及.NET比较有名的Entity Framework等等。

        我画了一张图来描述这几个概念之间的关系，主要是描述包含关系，个人理解而已：

 

设计模式（Design pattern：是一套被反复使用、多数人知道的、经过分类编目的、代码设计经验的总结。从定义上看，它涉及到了代码级别，侧重于解决实际的现实的问题。比如我们应该如何为不同的商品设计折扣的方式，采用策略模式呗。

框架（Framework）：是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。从定义看，它涉及到了一堆构件，以及这些构件之间的依赖关系、责任分配和流程控制等，说白了就是一堆类而已。这些类以及之间的关系构成了框架。比如想要让用户通过Servlet来访问页面，怎么办？用Struts呗。

架构模式（架构风格）：一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些呈先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。从定义上来看，它是在指导我们如何组织代码，是一种具有指导意义的思想，比如要解决系统的数据与显示分离的问题，那就使用MVC模式呗。

软件架构（software architecture）：是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。比如，我们要开发一个在线测评系统，使用什么架构呢？轻量级的SSH还是重量级的EJB？自己决定吧。

小结一下：

其实吧，软件这个行业的很多名词都没有特别准确的定义，好多概念是十分抽象和难理解的。但是回过头来看，我们不是做理论研究的，只要我们能够在问题的出现的场景中，使用最为合适的技术去解决它，就可以了。软件这行，纸上谈兵绝对是不行的，能为企业和公司解决实际问题，带来经济效益，促进信息技术转化为生产力，实现中国梦，乃我们最终的夙愿。