我刚接触struts，感觉struts其实就是MVC模式的标准化和框架化，不知道是否是这样？ 个人认为，struts实际上就是以下模式的缩微框架
1.前端控制器模式 前端控制器模式对常见的请求处理工作集中控制，并委托给下一个视图。集中请求处理保证这个工作不会交织在不同的视图中，使维护和扩展变得十分方便。前端控制器模式还将表示逻辑和导航逻辑分开，使它们之间互相不影响。
2.视图帮助器模式 视图帮助器是一个视图数据的分析器和持有者，视图帮助器负责将表示层提交的请求数据与其它表示层数据分离，并采用某种数据结构持有这些数据。另外，视图帮助器还根据不同的请求数据创建用于处理这些数据的对象。
3.命令模式 将请求和请求的处理过程封装为一个命令，并调用业务逻辑层处理请求。由于每一个请求对应一个处理命令（对象），因此很容易添加新的请求处理命令，而不影响其它的命令。
4.抽象工厂模式 负责封装对象的初始化过程，提供统一的对象调用接口。在控制层中，抽象工厂模式用于创建不同的具体命令。
是这样吗？ 如果是这样，那么我宁可自己作自己的MVC框架，更灵活一些。
我还没有系统学习struts，各位前辈多多指教。
理解正确，如果想推翻Struct，欢迎。 不过，正如Linus Torvalds 说的， 你的想法和观点都不错，我喜欢，不过要说服我，请 ------give me the code.
我完成了代码但是没有发子写在这里，贴序列图一张，聊表寸心
一个问题，您View中的部件(如按钮)是由Controller生成并与数据绑定的，还是由开发者自己做后期绑定？
由开发者自己做后期绑定
struts的做法是由controller去生成。好处是，开发者可以把工作重点放在界面开发上。使用框架的目的是可以把绑定的动作交给sturts servlet去作。而您的模型中由于是后期绑定，那么开发者除了前期处理界面的开发，还要自己考虑和编写界面和有关数据的捆绑和传递。开发时间相对增长。而且与不使用框架的区别不大。
struts的使用比较是适合分工很明细的开发小组，各开发模块可以通过struts-config.xml进行整合。
一般情况下。使用普通jsp或自己开发的框架会更适合每个人（开发团队）不同的开发习惯或环境。Struts是某些人的一种思路及其具体实现，不是最完美的通用解决方法。在实际应用中。可以（应该）按照自己所需要的特性进行修改。
这么快就写完代码，英雄！
倒掉。。banq的这个论坛为什么每次发帖子都让我输一次用户名和密码
thinkhard，我要抗议了
我好奇。您是不是用rose建模并生成代码？
用Rose建模，但是没有用它生成代码，因为它生成的代码很难看:( 关于JSP页面中的代码我是这样认为的： 无论使用Taglib、struts还是一般的代码，Jsp中总是有一些非html的东东，这是必须由page designer完成的。我的原则是不要将业务相关的代码放到jsp，不要将new操作符放到jsp（用factory封装），jsp只完成与用户交互相关的工作。
再问一句，struts是否会生成很多处理action的类？我作得这个框架会产生很多command类,还要用factory＋xml管理它们，郁闷中...
struts的设置有其矛盾的地方。按MVC来说V跟C是因该各干各的，由M去检验其职能。但struts为了让服务器干更多的活，就干脆在JSP里面加入了不少逻辑类型。所以这与您理解MVC的概念有出入，我是不是可以这样理解呢？
至于您说的page designer的活，按流行的看法，结合您提出的问题。很多应是人机界面类的东西，至于数据绑定类的活，您认为应该是server端代码人员应该负责的，是这个意思吧？
但是不知道，您有没有想过，如果您学要用server去规范jsp各部件权限的问题（不是指输入资料校验）而是指比如节点树的问题。如果好像banq他那个例子的做法外观肯定不好看，他是全由servlet去干了。而如果用html自己去管理的话，一些不必要的代码可能又会暴露在用户的眼底下...
作为servlet的代替品，jsp本来就是想让开发者更好地设计界面，而非逻辑处理。可是呢，我们看一下现实世界，搞网页的电脑公司，真正能让UI开发者和逻辑编写者和业务分析员这些角色分清的，一般都是一个人全包了，因此，在页面的开发上，jsp算是可以平衡这一尴尬的开发：既可以写代码，又可以写页面，你看，多方便啊。PHP、Phyton、ASP...等等东西都跳不出这个现实，因为这是80%的市场现实。至于Struts，它的立足点是想把servlet和jsp的地位模糊化...。
在最近由一些同事的开发应用中看到一个比较明显的问题，大家都只把Struts当流控制器（指ActionServlet）用了，但到了需要非指向性问题的时候（例如在当页生成报表）却又用回model 1那种思维去编写jsp。实在是...理论和实际的出入很大啊，这一点跟EJB大家一般只用SB去调配数据一样。不是struts或EJB的问题。而是开发者的习惯和模式，不是说改就改的...
最后，structs处理action的方法比较直接，用完就扔，要用的时候再生成，所以不会生成很多处理action的类。
struts的设置有其矛盾的地方。按MVC来说V跟C是因该各干各的，由M去检验其职能。但struts为了让服务器干更多的活，就干脆在JSP里面加入了不少逻辑类型。所以这与您理解MVC的概念有出入，我是不是可以这样理解呢？
至于您说的page designer的活，按流行的看法，结合您提出的问题。很多应是人机界面类的东西，至于数据绑定类的活，您认为应该是server端代码人员应该负责的，是这个意思吧？
但是不知道，您有没有想过，如果您学要用server去规范jsp各部件权限的问题（不是指输入资料校验）而是指比如节点树的问题。如果好像banq他那个例子的做法外观肯定不好看，他是全由servlet去干了。而如果用html自己去管理的话，一些不必要的代码可能又会暴露在用户的眼底下...
作为servlet的代替品，jsp本来就是想让开发者更好地设计界面，而非逻辑处理。可是呢，我们看一下现实世界，搞网页的电脑公司，真正能让UI开发者和逻辑编写者和业务分析员这些角色分清的，一般都是一个人全包了，因此，在页面的开发上，jsp算是可以平衡这一尴尬的开发：既可以写代码，又可以写页面，你看，多方便啊。PHP、Phyton、ASP...等等东西都跳不出这个现实，因为这是80%的市场现实。至于Struts，它的立足点是想把servlet和jsp的地位模糊化...。
在最近由一些同事的开发应用中看到一个比较明显的问题，大家都只把Struts当流控制器（指ActionServlet）用了，但到了需要非指向性问题的时候（例如在当页生成报表）却又用回model 1那种思维去编写jsp。实在是...理论和实际的出入很大啊，这一点跟EJB大家一般只用SB去调配数据一样。不是struts或EJB的问题。而是开发者的习惯和模式，不是说改就改的...
最后，structs处理action的方法比较直接，用完就扔，要用的时候再生成，所以不会生成很多处理action的类。 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 多谢！看来我有必要再好好学学struts。 提外话：Weblogic的console左侧的tree是用applet作的，也很好呀。要是有时间作一个通用的。
asdf
为什么什么东西都要自己从头做？如果你只是做基础平台开发的，可以，如果还要完成业务目标，你有精力完成你开发的平台的维护吗？