刚学J2EE企业级应用的时候几乎所有人都谈到MVC那时候学JSP+SERVLET+JAVABEAN的过程，正好符合MVC三层，也自以为了解了
后来看了《企业应用架构模式》，MF讲解J2EE企业应用分为 表现层-领域曾-数据层，我开始迷惑（姑且认为是V-C-M）吧
等后来了解了SSH，发现不对劲了，按照MF的讲解，C层用来隔离VIEW层与MODEL层，为VIEW层的请求分配处理单元，并将V层数据封装成MODEL供处理单元处理，那可见在SSH中Struts的JSP为V，ActionServlet为C，FormBean为M，Struts自身已经提供了完整的MVC，那么Spring和Hibernate放在MVC什么位置看待呢？Spring更像一套管理工具集为开发者提供封装好的方法，在MVC中并没有指出有这样类似对应的一层，难道传统的MVC模式并不足以描述整个J2EE的框架，至少很多元素在MVC中找不到对应关系。。。
而MF说的表现层-领域曾-数据层，仿佛MVC又全部集中在了表现层。。。
[b]问题补充：[/b]
这可这样理解，jsp，struts组成了C和V层
Hibernate组成了M层
前一句认同，“Hibernate组成了M层 ”欠妥，其实我理解的M层也许就是POJO，Hibernate提供了M层向数据库的映射机制
[b]问题补充：[/b]
其实我认为说FormBean为M也没问题，没人规定非要领域对象才能称为 Model，而一般封装的数据对象就不属于Model吧？
[b]问题补充：[/b]
aidiyuxin是说把业务数据的封装、业务的处理过程、对数据库的操作全归为模型层？
我突然觉得MVC这种描述到M嘎然而止了，没有描述业务处理单元所在的位置，我猜想MVC作为一种软件设计风格被用作构建多种类型的程序，其中包括J2EE，WEB应用，可能MVC在描述其他比如一个窗口程序的时候可能不涉及业务单元、数据库的问题。这也是为什么MVC在描述单一J2EE，WEB类型应用的时候缺乏表达力的原因。而表现层-领域曾-数据层则是MF为J2EE量身定做的。
另外一个现象就是：JSP+SERVLET时候，人们（包括书本）经常提到MVC，等到了SSH，EJB的时候很少人（书本）提到MVC，取而代之是表现层-领域曾-数据层。。。
[b]问题补充：[/b]
在ROSE建模里有一种划分类的方式“边界类”“实体类”“控制类”，我觉得这和MVC是对应的，ROSE里能引入这三类划分方式，可见M-V-C模式不是WEB应用特有的，相反，是WEB应用觉得使用M-V-C模式更容易构建。MVC是一种软件体系风格，任何软件都可以使用MVC风格构建，但是，一个桌面应用程序说什么也不可能使用表现层-领域曾-数据层构建，那是WEB应用特有的模式，这就是MVC和表现层-领域曾-数据层的区别，然而MVC在更高层次上描述WEB应用显然没有用WEB应用特有模式表现层-领域曾-数据层描述的更准确，《企业应用架构模式》名字也很能指出，这里描述的是企业应用“特有的”架构模式。
[b]问题补充：[/b]
"个人觉得说这东西是风格有些不妥，他是一种设计模式，不应该数据风格，大家一般说的什么编程风格不是设计模式"
阎宏博士在《JAVA与模式》中将模式分为 架构模式-设计模式-代码模式，其中MVC属于架构模式，平常说的工厂什么的属于设计模式，明显MVC不是设计模式，23个设计模式里也没有MVC的赘述。
另外在林巴斯在SEI写的那本软件体系风格的书中，提到了将软件习题风格分为：分层，黑板，管道过滤器等等风格，凌驾于具体模式之上，MF在《企业应用架构模式》中也提到了J2EE选择了分层风格，而且期待未来某天有人能实现管道风格的企业级应用框架，MVC又是分层风格中最经典的一种分层方式。
[b]问题补充：[/b]
“同样不明白楼主为什么叫mvc为：表现层-领域曾-数据层
mvc这个设计模式兴起的时候领域模型的概念还没有风靡”
其实按照MF的描述，我大概可以想象 表现层就已经实现了完整的MVC，实际上这里的V并不指JSP，只是表现层的MVC中的V是JSP，如果你想开发一个构建，这个构建只给构建使用者提供数据的统一视图，这个试图也可以称为VIEW，这个构建也能实现完整的MVC。
[b]问题补充：[/b]
"这里要指出下，rose建模和现在楼主所说的mvc不是一回事，不要拿rose的这些东西去理解面向对象语言中的设计模式，两个是不一样的，有一定差别 "
在JSP+servlet+javabean时候，我们确实用ROSE的“边界类”“实体类”“控制类”来为WEB应用建模，表述的很清楚。
[b]问题补充：[/b]
"狂晕，Hello World 还能实现mvc呢 "
你对表现层理解是不是狭隘了,表现层不仅包含这个页面该显示什么,还包含考虑这个页面的连接应该让这个页面跳转到哪个页面,这个完整过程才能是 表现层-领域曾-持久层 中的表现曾
[b]问题补充：[/b]
"那还分什么层啊？这不又耦合在一起了么？"
我认为解藕不可能无限制的解,藕合低到一定程序再解就存在过度设计了,有可能复杂度反而上升,表现层和控制层的藕合肯定是解不掉,这是个下限
[b]问题补充：[/b]
"咱们将了一周了，交个朋友吧~ "
好的啊,这个问题就此作罢吧
