对学习日志的一点建议

能否在下一个版本里不用struts.这个框架很落后.缺点很多.

其实我们这个系统不是很大.用框架好的作用起不到反而会限制系统的灵活性.

我们可以参考一下struts.参考一下mvc.在设计的时候尽量用到他们的思想.但是不能让自己局限在这些死的框架中.可以我们自己设计,分工.做起来也会很有乐趣的。.

4 thoughts on “对学习日志的一点建议”

  3. 本质上说struts还是一个基于jsp的解决方案，所以不可避免的解决不了

    jsp最本质的问题。各种逻辑和页面的混乱，解决不了交互性问题，后面再提。

    1。tag lib,这是struts最引以为豪的地方，直接的问题有几个，

    学习周期长，一端时间不用就会忘记

    扩展并不容易，远低于用脚本或者xslt的开发效率，新版的jsp2.0这方面有改进，但是暂时体现不到struts上来。

    在页面引入tag以后，其实某种意义上逻辑更加混乱，如果没有好的可视化集成环境的支持，开发效率低、维护成本也高。

    我经过1，2年的使用，我觉得tag lib的方案比起类似velocity的模版语言有显著差距，本来引入的目的是为了页面逻辑和表示逻辑，但最后达到的普遍效果是更加混乱。对于美工要求高的页面，美工根本没办法动手。结果我发现，现在很多人用struts，干脆就避免用他的tag,主要使用action来提供控制机制。

    还是模版语言，组件方式的做法解决的更干脆。

    2。配置文件。

    在1.0的时候只支持单个文件，大项目很容易超过几m,协同开发的时候是个灾难。1.1以后可以放置在多个文件，但是一句话，如果没有整合的工具，维护始终是个问题。1.1以后引入的commmon validation,把维护工作进一步增加了。

    开发工作中有很多时间都花在解决这些冲突上，所以不得不考虑自己编写教研工具。

    3。层面太多，做小应用不适合，远不如jsp+bean的方式简洁快速。

    做大应用的话，因为他只是一个表现层的东西，不能单纯的解决问题。

    要和复杂的框架结合需要费电功夫，所以还不如直接用别人弄得业务框

    架，除非是自己开发平台。

    4。和asp.net那种事件驱动机制的前台框架相比，对交互性要求比较高

    的应用。开发效率太低了，

  4. 在java的web应用中,它的开发思路很明确,容易理解,同时对学习其他的开发语言也有很多的帮助.

Comments are closed.