有些混乱了，MVC怎么区分？？

在struts里面，你不用负责写 controler， struts的action是用来写business logic的。这是最基本的方式。

struts的里面的也有 ActionServlet，这个是用来为定制controler的，你可以用这个ActionServlet来定制自己的controler。你也可以用struts自己的controler，只需要在xml文件里面配置 action mapping就可以了。

我觉得，MVC更重要的是从一个逻辑上来表述的一个概念，既如何将应用分层，以便于扩展和维护。

你当然也可以把 controler和view的部分都写在jsp，既直接用jsp调用action，或者直接用jsp调用EJB，但那样的架构基本上就没有什么扩展性和维护性可言了...

我也是初学者，只做了个小应用，一点体会小小讨论一下...

我们课上学j2ee的时候，struts那章的slide，action那部分写的logic
http://www.jdon.com/jivejdon/message/upload/show.jsp?type=images/jpeg&id=0
[该贴被thinkriver于2008-10-20 08:16修改过]

正统MVC三层模型中，没有表述“业务逻辑层”也没有表述“数据层”，看似MVC模型并不足以构建整个企业应用

我想，C控制器的作用是说控制某个请求由哪个处理器处理，然而现在开发中，选择由哪个处理器处理很多是通过URL参数直接指定的，那么ActionServlet确是Controller，而迹象情况下，有些人写出代码每个url都指向不同的Servlet，选择Servlet过程完全由URL来做，这里的Servlet还能算作Controller了么。。？

软件用 MVC 设计，其中的MVC可能指的是架构风格

而MF说的，表现层-领域曾-数据层 分层则是具体的整体架构，指导开发的

这两种分层的关系是什么？难道MF的分层是对MVC的进一步补充？

MF说 控制层用来隔离表现层与模型曾，让二者可以独立演化，减少表现层与模型层依赖，这里明显指出控制层为Servlet,Action，表现层为Jsp，那么传统的SSH，Struts就提供了表现层和控制层两层，难道Spring和Hibernate一起提供了模型层？还有一种想法是Spring提供了模型层的管理工具，Hibernate提供了模型层到数据库的映射工具，那么在传统MVC模式中，Spring，Hibernate又应该放在哪里看待呢？而如果SH无法放到MVC模式中考虑，那么把企业应用使用MVC模式的“MVC”是不是又缺乏足够的表述力呢？

MVC和MF提到的三层以及Evans DDD多层都没有矛盾。

MVC只是表现层也就是界面层的一个架构，其M代表Model，也就是领域层，或称业务层。C代表控制器模式，也就是GOF中Mediator模式，Mediator模式封装了通讯，实现前后台调度。

所以，不能在C中写有关Model的业务代码。servlet/Action或JSF的事件Action都是一种Mediator/Controller， Mediator/Controller和事件通讯有关，并且在Mediator/Controller中管理调度事件通讯方向，把握这个原则就很好掌握Mediator/Controller。

MF和DDD谈的是整个javaEE架构，JavaEE只有MVC是不够的，而Ruby这些脚本语言只有MVC就够了，业务代码写到C中，这在Java中是不允许的，缺点就是违反类的单一职责，C已经承担事件调度通讯等工作了，不能再承担其他职责。

在SSH: Struts+Spring+Hibernate架构中，显然Struts代表表现层，Spring代表业务层领域层 而Hibernate代码数据持久层，很基础的三层，当然只有三层还不够，业务层可分为领域层 应用层 等，可以再细分。Spring重点是业务层，由于其目标是发展一个JavaEE全API，也就是和JavaEE标准竞争，所以，它涉及方面更多，但是我们更愿意定位其原始出发点和特点，每个产品做好自己的擅长就可以，不要搞大而全，否则就用微软的，这已经是Java社区不成文的潜台词。

[该贴被banq于2008-10-27 13:58修改过]

那2楼同学图中说的ActionForm是否应该算作Model,因为毕竟来自于表单的元素封装,在传到领域层之前肯定要解包重组重新封装,有人认为重新封装的用于处理业务的数据封装对象才能称之为Model?这里等价于POJO,但是我确实没听说过表单封装不算Model,领域模型才算Model,书上也没这么写过,Struts书确实介绍Struts支持完整的MVC.

我是这样想的,如果你只用Struts,那么Struts支持MVC,如果你用SSH,那么相当于Struts只支持VC,而M托管给了Spring

>ActionForm是否应该算作Model,
可以认为算 界面模型，在Struts2及JSF中，已经将Domain Model和ActionForm合并，也就是用Domain Model直接作为界面模型和领域模型。

不管是否用SSH，MVC的Model总是在界面表现层需要的，否则你如何显示业务界面呢？可以将Model统理解为业务，Model业务虽然在表现层需要使用，但不代表一定要在表现层实现，这是两回事。

因此，无论只是有Struts或使用SSH，Model都要在表现层Struts中使用到，但是肯定不能在表现层实现，需要在专门的业务层实现Model，而与具体业务框架使用无关，你使用SSH，就使用Spring包装业务，使用EJB就是要EJB包装业务，使用Jdon框架就使用Jdon包装业务。

框架使用是服从架构设计的，框架选择也是架构一个重要内容。多层结构是架构设计一个基本基础。

那可不可以这样归归类:
1 MVC描述的是标准的客户\服务器模式中,服务器端的设计策略,比如我设计一个很简单的程序,客户在页面上输入什么,服务器上就显示什么,那么这个最简单的BS/CS模式应用程序,仍然需要完整的MVC来支持,但是它无法称之为企业及应用,没有业务.没有数据库.

2 MF的分层是标准的J2EE企业及应用分层,和一个标准的客户\服务器模式分层相比,服务器端还有有业务处理单元,服务器还要再次作为客户访问其他外界资源,比如DB,JMS,所以添加了领域层和持久层.

有人将J2EE企业及应用比作一个两头开口的容器,上口由终端用户罐数据,下口从各种资源JMS,DB等吸数据,也有人设计了一个平行体系结构,就是展现层和持久层实现一样,反正都发送或者接受得数据,那么是数据库还是终端用户都给封装在一起,那么哪层是数据库访问哪层是用户访问就不用考虑了反正都是对外界的通讯,当然这种做法也受到了MF的批评.

对于你描述的这两种情况其实就代表两个企业软件路线：
以数据库为中心 和以对象为中心。

第一种，只有MVC，但不是象你所说的没有业务 也没有数据库，可以有业务和数据库，业务就使用数据库SQL和存储过程来实现的，这类应用常见脚本语言php/perl/ruby等架构，MVC+关系数据库。这是很常见而且大量应用的低级程序，门槛低。缺点就是我一直批判的以数据库为中心，导致面向过程编程，SQL存储语句难于维护和拓展。

第二种，就是MF倡导的标准架构，不只是JavaEE，其他语言.NET也可以实现，出现了专门领域层业务层，这个层是来自于Evans DDD等OO建模分析的结构，将业务逻辑用对象方式表达，而不是数据库SQL，数据库SQL被隔离封装在持久层或数据层，和JMS 文件等其他数据源共同组成数据层，这时的数据库就不再是企业软件中心，是一个配角。而业务对象MODEL是主角。这也是我提出数据库时代终结，和数据库死了的原因。

struts本来就是一个MVC的完整实现，你说的servlet能做的事情jsp也能做，这句话不错，因为jsp编译以后就是servlet，但是在struts中C还是Servlet，这个Servlet不再是out.print("<td>...");之类的工作了，主要用来控制页面的流程的，所以我认为struts中jsp是V，Form和Bean是M（前台的数据），C就是ActionServlet和用户自定义的Servlet

先说JSP吧，我在最初接触的时候也跟楼主是一样的，觉得JSP和Servlet是不一样的，总感觉JSP就是页面，当接触的越来越多的时候才发现，其实他们是一样的。。。最初关注的是JSP和Servlet能做什么，不是怎么做的问题，所以思维就很模糊，非要搞明白到底什么是M什么V什么是C，后来接触到了Struts，最初也仅仅是使用，后来研究了一段时间，接触到一个概念：config-driver，也就是我们说的配置驱动，struts就是配置驱动的，这个词充分揭露了struts的一个核心本质：配置！也就是我们在实际项目中的那个Struts-config.xml文件，在我的理解里面，其实他就是Cotroller吧，我们的每一个request请求需要调用那一个Action或者是那一个DispathcAction的那一个方法，需要传递什么样的封装好的form对象，action处理之后的页面跳转，这一系列的表现层的动作，不都是在struts-config中配置的么？当然，这个xml文件自己是不能控制我们的流程的，这里就涉及到了ActionServlet，其实ActionServlet
就是一个控制的执行者，它根据strut-config的配置，控制请求。说到配置驱动，有不得不提一下还有另外一个概念：约定驱动。这个是和配置驱动对立的一个概念，在这个概念体系里边，我们少有配置文件，而是通过一种约定，比如用velocity作为view层，我们可以用这种模式去设计框架。个人认为没有必要去死扣MVC的每一个字母，有什么意义呢？有时间看看Struts源码，或者模仿一下struts的实现，不是挺好的么。

按照MF的,展现层+领域曾+持久层,传统M+V+C盒在一起是展现层的完整实现,MVC,另外,我始终不觉得M是一个层,而M是层与层之间传递的对象,与其说MVC三层,不如说MVC三种元素.