问题描述
刚学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又全部集中在了表现层。。。问题补充：这可这样理解，jsp，struts组成了C和V层 Hibernate组成了M层 前一句认同，“Hibernate组成了M层 ”欠妥，其实我理解的M层也许就是POJO，Hibernate提供了M层向数据库的映射机制问题补充：其实我认为说FormBean为M也没问题，没人规定非要领域对象才能称为 Model，而一般封装的数据对象就不属于Model吧？问题补充：aidiyuxin是说把业务数据的封装、业务的处理过程、对数据库的操作全归为模型层？我突然觉得MVC这种描述到M嘎然而止了，没有描述业务处理单元所在的位置，我猜想MVC作为一种软件设计风格被用作构建多种类型的程序，其中包括J2EE，WEB应用，可能MVC在描述其他比如一个窗口程序的时候可能不涉及业务单元、数据库的问题。这也是为什么MVC在描述单一J2EE，WEB类型应用的时候缺乏表达力的原因。而表现层-领域曾-数据层则是MF为J2EE量身定做的。另外一个现象就是：JSP+SERVLET时候，人们（包括书本）经常提到MVC，等到了SSH，EJB的时候很少人（书本）提到MVC，取而代之是表现层-领域曾-数据层。。。问题补充：在ROSE建模里有一种划分类的方式“边界类”“实体类”“控制类”，我觉得这和MVC是对应的，ROSE里能引入这三类划分方式，可见M-V-C模式不是WEB应用特有的，相反，是WEB应用觉得使用M-V-C模式更容易构建。MVC是一种软件体系风格，任何软件都可以使用MVC风格构建，但是，一个桌面应用程序说什么也不可能使用表现层-领域曾-数据层构建，那是WEB应用特有的模式，这就是MVC和表现层-领域曾-数据层的区别，然而MVC在更高层次上描述WEB应用显然没有用WEB应用特有模式表现层-领域曾-数据层描述的更准确，《企业应用架构模式》名字也很能指出，这里描述的是企业应用“特有的”架构模式。问题补充："个人觉得说这东西是风格有些不妥，他是一种设计模式，不应该数据风格，大家一般说的什么编程风格不是设计模式"阎宏博士在《JAVA与模式》中将模式分为 架构模式-设计模式-代码模式，其中MVC属于架构模式，平常说的工厂什么的属于设计模式，明显MVC不是设计模式，23个设计模式里也没有MVC的赘述。另外在林巴斯在SEI写的那本软件体系风格的书中，提到了将软件习题风格分为：分层，黑板，管道过滤器等等风格，凌驾于具体模式之上，MF在《企业应用架构模式》中也提到了J2EE选择了分层风格，而且期待未来某天有人能实现管道风格的企业级应用框架，MVC又是分层风格中最经典的一种分层方式。问题补充：“同样不明白楼主为什么叫mvc为：表现层-领域曾-数据层 mvc这个设计模式兴起的时候领域模型的概念还没有风靡”其实按照MF的描述，我大概可以想象 表现层就已经实现了完整的MVC，实际上这里的V并不指JSP，只是表现层的MVC中的V是JSP，如果你想开发一个构建，这个构建只给构建使用者提供数据的统一视图，这个试图也可以称为VIEW，这个构建也能实现完整的MVC。问题补充："这里要指出下，rose建模和现在楼主所说的mvc不是一回事，不要拿rose的这些东西去理解面向对象语言中的设计模式，两个是不一样的，有一定差别 "在JSP+servlet+javabean时候，我们确实用ROSE的“边界类”“实体类”“控制类”来为WEB应用建模，表述的很清楚。问题补充："狂晕，Hello World 还能实现mvc呢 "你对表现层理解是不是狭隘了,表现层不仅包含这个页面该显示什么,还包含考虑这个页面的连接应该让这个页面跳转到哪个页面,这个完整过程才能是 表现层-领域曾-持久层 中的表现曾问题补充："那还分什么层啊？这不又耦合在一起了么？"我认为解藕不可能无限制的解,藕合低到一定程序再解就存在过度设计了,有可能复杂度反而上升,表现层和控制层的藕合肯定是解不掉,这是个下限问题补充："咱们将了一周了，交个朋友吧~ "好的啊,这个问题就此作罢吧
解决方案
呵呵~不能白写这么多呀~帮选个最佳答案吧~
解决方案二：
引用我认为解藕不可能无限制的解,藕合低到一定程序再解就存在过度设计了,有可能复杂度反而上升,表现层和控制层的藕合肯定是解不掉,这是个下限 表现层和控制层耦合在一起了，你还维护不了？不有回到了，一篇字<%%>的时代了？这不现实啊，如果c，v分层都不要的话如果你的软件不分层架构的话，完全不存在可维护性，只有极低的扩展性引用有可能复杂度反而上升,表现层和控制层的藕合肯定是解不掉摆脱了，楼主，你好像真走墙角啊，解耦不是完全没有耦合如果完全没有耦合的话，模块之间就没有联系了解耦是指降低耦合度ps：咱们将了一周了，交个朋友吧~其实设计的问题上争议太多了，谁也说服不了谁
解决方案三：
引用你对表现层理解是不是狭隘了,表现层不仅包含这个页面该显示什么,还包含考虑这个页面的连接应该让这个页面跳转到哪个页面,这个完整过程才能是 表现层-领域曾-持久层 中的表现曾 狭隘？不觉得啊引用连接应该让这个页面跳转到哪个页面发生跳转啦，应该去过c层，m层啦看来楼主还是不理解什么是分层啊如果包括了你说的那些东西，还要c层和m层做什么 啊？每一层都有他专门要做的东西照你所说的引用表现层不仅包含这个页面该显示什么,还包含考虑这个页面的连接应该让这个页面跳转到哪个页面,这个完整过程才能是 表现层-领域曾-持久层 中的表现曾那还分什么层啊？这不又耦合在一起了么？
解决方案四：
引用在JSP+servlet+javabean时候，我们确实用ROSE的“边界类”“实体类”“控制类”来为WEB应用建模，表述的很清楚。我是说用一定的差距，没有出完全不能如果rose真的不能帮助理解，那要他何用啊？rose是建模用地，mvc属于设计模式，两者有一定得差距希望楼主不要把设计模式和建模混淆
解决方案五：
引用阎宏博士在《JAVA与模式》中将模式分为 架构模式-设计模式-代码模式，其中MVC属于架构模式，平常说的工厂什么的属于设计模式，明显MVC不是设计模式，23个设计模式里也没有MVC的赘述设计模式又不是只有23种。。。
解决方案六：
其实按照MF的描述，我大概可以想象 表现层就已经实现了完整的MVC，实际上这里的V并不指JSP，只是表现层的MVC中的V是JSP，如果你想开发一个构建，这个构建只给构建使用者提供数据的统一视图，这个试图也可以称为VIEW，这个构建也能实现完整的MVC。引用表现层就已经实现了完整的MVC狂晕，Hello World 还能实现mvc呢引用实际上这里的V并不指JSP谁也没说表现层一定要是jsp啊只要吧数据展现出来，就是V引用如果你想开发一个构建，这个构建只给构建使用者提供数据的统一视图，这个试图也可以称为VIEW，这个构建也能实现完整的MVC。当然，设计模式怎么用都可以一个Hello World 还能实现mvc呢但是没人会这么做，因为这么做没价值
解决方案七：
引用在ROSE建模里有一种划分类的方式“边界类”“实体类”“控制类”，我觉得这和MVC是对应的，ROSE里能引入这三类划分方式这里要指出下，rose建模和现在楼主所说的mvc不是一回事，不要拿rose的这些东西去理解面向对象语言中的设计模式，两个是不一样的，有一定差别引用可见M-V-C模式不是WEB应用特有的确实不是web中特有的引用MVC是一种软件体系风格个人觉得说这东西是风格有些不妥，他是一种设计模式，不应该数据风格，大家一般说的什么编程风格不是设计模式引用《企业应用架构模式》不知道楼主为什么总是引用这本书，个人不是喜欢这本说，他把大家常用的设计模式封装了，并冠以名词，我觉得这样做不是很好，说是设计模式，还不想，说是建模，也不是引用MVC和表现层-领域曾-数据层同样不明白楼主为什么叫mvc为：表现层-领域曾-数据层mvc这个设计模式兴起的时候领域模型的概念还没有风靡
解决方案八：
分析楼主的文字，个人分析您的问题主要集中在两点上：1、VO，PO，POJO概念的混淆，造成了您在MVC上的主要迷惑点2、Spring如您所说是有很多帮助类，其实最初我认为spring是无用的东西，但是后来学习中发现spring绝对是个内功深厚的大师。他是一个管理者，所有的资源（当然您要让spring来管理它们）以bean的形式交给他来管理，这叫依赖注入；同时举个例子，比如事务管理，如果你不用spring来做的话，那是很累人的，事务管理通过spring的拦截器来实现，这叫面向切面。还有其他任务调度，JMS等EJB才有的东西，我们用spring就能做到。这绝对是一门值得掌握的技术、思想。struts2我只是了解了一下，没有在项目中用过。但是Spring是可以独立实现MVC的。回过头来说第1点：随便找一本Hibernate的书，都可以找到这样一节：对象在Hibernate中的状态：瞬时、持久、脱管。详细的状态转换请查一下，和DAO操作或者说数据库操作有关，和生成方式有关。注意！这里的状态是发生在同一个对象上的，这个对象是什么？就是你的model层对象，比如Person类，它对应了表PERSON_TABLE。我们是怎么使用它的呢？页面要传值，要new一个Person。这个叫VO，Value Object。查数据库得到一个Person，这个叫PO，Persistence Object。当然不仅限于此。前者我们让Person出现在了View层，后者我们让Person出现在了Model层，好像违反MVC？个人认为确实违反了。但是这样做在某种程度来说是合理的，不是吗？难道为了不打破结构就多写一个一样的类就合理了吗？那VO不是没有必要了吗？再看一个例子。Person里有生日，时间在存往数据库的过程中通常是由java.util.Date转化的，具体过程不说了，请自查相关API。页面的时间是string类型的，如果从数据库拿出这个时间传到页面上，不做处理的话将显示yyyy-MM-dd HH:mm:ss.ssss 这样做显然是不合理的，我们要的是 yyyy-MM-dd。我个人是写一个PersonTemp的javaBean，这个其实和Person是一样的，里面也有birthday 这个是Date类型的，然后在PersonTemp里有个birthdayTemp，这个是String类型的。这个PersonTemp就是VO，这个也可以用ActionForm来做。最后我还会写一个接口，其中都是PO和相关VO相互转化的方法。不知您对PO，VO有了解么？那么POJO是什么呢？这个的由来其实是同EJB相对的。POJO其实就是JavaBean，Plain Old Java Objects，通常叫简单Java对象。最后再说说对MVC的感受，说实在的我工作经验也不多，我刚做完一个项目，是用MVC的。没什么感觉，但是最近改公司的一个老项目，傻眼了，Action出来了就调DAO，甚至没有DAO，直接JDBC拼上SQL了，天书！头次看见超过50行的SQL语句。这种代码几乎没有维护的可能，页面也是，一个页面300多行Java代码。个人感觉 MVC，面向对象是相当重要的思想，有思想的coder，一个页面都是面向对象的。多了很多，希望对您有帮助。
解决方案九：
哎，看来楼主不是很明白mvc的情况下看了很多夸夸奇谈的东西呢mvc的最简单的意思就是这里有一份数据 ， 我怎么把这份数据 ， 展现给别人
解决方案十：
引用前一句认同，“Hibernate组成了M层 ”欠妥，其实我理解的M层也许就是POJO，Hibernate提供了M层向数据库的映射机制呵呵，每个人的理解都不一样，M是要吧数据持久化的，Hibernate完成了吧数据持久化的过程其实我这么说你要让你吧3个框架的用途弄明白M层也是要分的dao层持久层如果有的话orm数据库他们共同组成了数据库Hibernate在上三个层面上都有参与引用其实我认为说FormBean为M也没问题，没人规定非要领域对象才能称为 Model，而一般封装的数据对象就不属于Model吧？这是不对的，FormBean的生命周期在C层已经结束了
解决方案十一：
引用表现层-领域曾-数据层这个貌似楼主暂时不用去理解他这一种建模的表现，他引入了领域模型的概念这样可以根据不用的领域模型符合不用的业务引用那可见在SSH中Struts的JSP为V，ActionServlet为C，FormBean为M这样理解是有偏差的，struts主要是C层，并提供了V层的支持FormBean只是将V层的数据传递到C层的GTO，和M层一点关系都没有M层指的是模型层，大多数是指数据库层的这可这样理解，jsp，struts组成了C和V层Hibernate组成了M层spring将C层和M层连接起来