偶现在在公司当什么鸡竖总奸（以上文字用于测试jive的过滤功能），在其位某其职，所以总想玩儿点玄乎的东东，而且又是编程迷...惭愧ing
您说：在最近由一些同事的开发应用中看到一个比较明显的问题，大家都只把Struts当流控制器（指ActionServlet）用了，但到了需要非指向性问题的时候（例如在当页生成报表）却又用回model 1那种思维去编写jsp。实在是...理论和实际的出入很大啊，这一点跟EJB大家一般只用SB去调配数据一样。不是struts或EJB的问题。而是开发者的习惯和模式，不是说改就改的...
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
这样是可行的，petstore就采用了这中方法，叫做什么fast_l...，想不起来了，反正就是允许view层直接访问只读的DAO，我在项目中也采用了这种方法，效果不错，简单多了。
但是如果是update、insert等操作，还是要走标准的MVC道路的。
我不是说那种做法是不可行，不过用起来和做起来的感觉不是好像petstore那种因为应用需要而去干，而是因为习惯。我的同事，一开始是按MVC的，做着做也就又按照原来的习惯去做了，结果另外一些习惯了Struts-MVC的同事接手做一下步的时候又变得不习惯这些编码方式了。
其实这就我说的问题倒不是JAVA或MVC本身的技术问题。技术本身的效果是很明显的。倒是觉得是项目管理会出现的问题。比如说，在一个开发组里，各开发人员对技术的接受和理解程度都不一样，在用一种新开发模式的时候，到底有没有提高开发效率，还是结果降低了？这些问题才是最头痛的。
补充一下，jboss也是用applet做树的，applet有很多jsp比不上的东西，特别是界面的灵活性。不过这个讨论方向再下去的话，又变回了B/S、C/S的优异论，咱们提一下也就算了吧。
如果重新开发这样的框架，耗时耗力不值得而且未必有STRUTS好。当然如果项目不大，开发人员不熟悉STRUTS，Front Controller 模式也够好了
MVC主要是为了能明确分工和大家不用依赖对方，但实际上却很难做到这一点，就连近来很热的JSF我觉得也并不能做到UI的理想。怎么说呢？MVC原来的想法是美好的，但好象和人类（或者说逻辑）是想违背的，你怎么能设计了前面不用看后面呢？不知道是不是我对MVC的理解有问题，其实我总觉得MVC到现在还没有真正脱离原来的jsp+servlet(javabean)。
还有STRUTS是J2EE设计模式的结晶，我觉得这句话真的是有道理的。在我看来 它实现了大部分的J2EE设计模式！
我也是个新手！有不对的地方，请大家多多指教！ありがとう。おいします。
> 隹蚣芑岵芏command类,还要用factory＋xml管理它们，?> 闷中...
我的做法是：在actionmapping中定义许多forward,然后通过在request中传参数（uiaction)来实现一个（或者几个，要看模块划分了）action对所用请求的转发，这样做的好处是：
1。action类不会爆发
2. 日志及异常的集中管理。
这也是一种facade吧
你可不可以考虑一下，使用java.lang.reflect，将一组处理Action的Comamnd放在同一个Class中，用每一个Method对应一个Command类，它们有相同的接口，这样就不需要太多的Command类了. 我自己写了一个MVC Controller就是这样玩的,用起来还不错. 在几个项目中,开发和运行效率都非常地高, 配置也很简单明了,没有struts那么复杂.
你可不可以考虑一下，使用java.lang.reflect，将一组处理Action的Comamnd放在同一个Class中，用每一个Method对应一个Command类，它们有相同的接口，这样就不需要太多的Command类了. 我自己写了一个MVC Controller就是这样玩的,用起来还不错. 在几个项目中,开发和运行效率都非常地高, 配置也很简单明了,没有struts那么复杂.
所有html中需要显示的变量都通过特殊的tag来标记
一个html对应一个jsp页面,a.jsp<->a.htm
jsp页面作为view层去符合MVC的标准,只不过从html中获得
显示的代码.这样page designer可以完全脱离程序来进行
page的制作.
|