我们在Web层放弃的一些东西

这是我们的开发团队在最近1年的开发中放弃的一些东西。想听听大家的看法。

放弃Apache：

我希望我们的软件不经过任何修改就能运行在不同OS的服务器上。这样对部署和维护成本都有利。纯Java和像PHP这样的脚本语言可以适应。但JVM的安装要比脚本执行引擎的安装方便得多。

任何基于Web的app都必须依赖Web Server。apache的代码非常成熟，可以在任何的类Unix平台上顺利的make install，Linux、FreeBSD、Aix、MacOSX甚至Irix。但如果采用PHP，你就不得不在编译apache的时候，加入一堆参数以引入各种模块，包括最起码要包括php和mysql。（mysql需要编进php里）。非常麻烦。mysql如果升级了，很可能会引起mod_php也需要重新编译。经验丰富的系统工程师可以通过各种手工的link来伪装libmysql、libphp以及其它lib之间的版本差异，但依然要费很多的功夫。如果把mysql再换成Oracle或者DB将是更加痛苦的过程。

更困难的是，除了Linux和FreeBSD外，在其它的类UNIX的编译安装都需要点儿不同的参数调整。如果那台服务器已经由于其它应用软件的安装而更改了/usr/lib/下的一些东西，那很可能会給部署带来不小的麻烦。

于是在综合考虑后，决定放弃apache选择tomcat——纯Java的跨平台的Web Server，PHP也被随之放弃（放弃PHP有很多理由，这也是其中之一）。好在v5.5以后，tomcat的效率已经可以令人接受了。我甚至把任何静态的页面都放在tomcat中，而不是另外安装一个apache用来处理静态页面的请求。测试下来，tomcat处理静态页面的效率也没什么问题。

最终我们把整个JSDK、tomcat、jsp、jar、class、servlet class都tar成一个包，传到服务器上一解包就安装完毕了，立刻可以运行。

放弃struts:
用struts开发项目的前3天，struts强迫性的分离mvc的方式很令人愉快。但之后的3个月，我逐渐失望，3个月后我盯着臃肿庞大的XML开始抓狂！
这时我意识到一套良好的文件目录组织结构 ＋ 清晰的文件命名规则 ＋ 简要的文档 要比struts更有效。
于是，我们按照RoR的目录组织格式来区分负责MVC的程序。

放弃Servlet：
按“道理”，处理action的都应该是一些extends HttpServlet的Class。几乎所有教科书的例子都是这样。但我特别讨厌在web.xml里写进一堆mapping、name、pattern和server-class标签（其实我讨厌手工修改任何XML文件）。
所有该创建的class XXX extends HttpServlet都由xxx.jsp来实现了。这种jsp不print任何HTML，只是getParamenter和get/set Session，然后调用service层的方法，最后redirect到其它action或者view。
Jsp会被tomcat编HttpServlet class，但这个class不能加进任何方法。这样可以“强迫”你将尽量多的逻辑代码都写入service层。
只有在很特殊的一些地方，才不得不写少量的Servlet，比如download 或者write动态图像。

添加、删除或者rename一个action的时候，我们再也不用去反复维护web.xml了。


放弃frameSet：
HTML里的frameSet标签经常被用来分割页面上的不同功能区域，这有利于用户在不同的功能模块之间切换。但从UI的角度来看，使用者又总是希望屏幕应该用尽力大的区域来显示他正在关注的版面。
如果你只用一个Page frame，那么每个用户的view page都必须包含一些固定内容，比如Head或者left bar。有各种各样的jsp标签顺应这个需求被发明出来。但这无疑会增加用户浏览器对无用数据的下载量。
现在有了ajax。我们把整个app都放在了一个page里。需要更新的区域用ajax做局部更新。小型表单的提交直接用get method放在url后面，大型表单的提交用hidden的iframe来完成。
一切都很完美，但浏览器的后退键在我们的app中从此失效 。

Welcome to earth

寒,把jsp页面当作Servlet入口来用.要是你在JSP里调用的类或者方法改了名字,你只得手动去JSP里查找替换.JSP编辑起来爽么?还用frameSet做header,用js文件不更方便?或者搞个隐藏菜单的功能......不清楚lz想说什么..........
PS:做了一个项目,因为某些原因,全部用纯JSP实现,现在一想起就要吐,不爽啊不爽,然后lz又勾起了我伤心的回忆....

“把jsp页面当作Servlet入口来用”——除了查找替换困难的缺点，还有什么其它的缺点？

原以为有了sitemesh就不用frameset了，后来发现如果模板页数据过大（如每页左侧都拉个QQ那样的分组栏），不用frameset的话页面响应速度真叫慢。AJAX是节省了带宽，不过如果用得过火，浏览器的假死也让人受不了。这三种技术还是量身裁衣吧

一个理论和实践功底都不错的人物Canonical，做了一个不错的框架jsplet，也采用了JSP作为Control Entry。

http://forum.iteye.com/viewtopic.php?t=11726

这样的好处是，不需要Struts, WebWork, spring mvc或者大部分框架那样的统一的 url -> action配置文件了。

这个思路还是挺有启发意义的。从某种意义上来说，至少从一个中心，变成了多中心。（或者极端的情况，就是无中心，就是Page Centric，不过楼主说，jsp controlet 里面没有太多代码，主要是做dispatch。就应该不是单纯jsp 从查询数据到输出HTML所有工作的那种Page Centric）。

统一的config文件的一个问题就是，当模块很多的情况下，不容易管理。struts, webwork等都支持多个config文件，但最终只是攒在一起。
而没有如同c++ c# namespace, java package, class, method 那样的高级语言级别的module概念。

jsp controlet 不利的方面，主要就是重构、调试不方便。
如果jsp code不多，问题不会特别严重。
如果jsp的个数太多，可能有一些问题。jsp编译时间，webserver对Servlet的管理。等。

jsp controlet 的思路，我也借鉴了一些。
当然我不是用jsp做control，因为我也无法忍受代码逃出IDE的控制，跑到template里面去。IDE里面的代码，都管理不过来，那些编外人员更是难以管理了。
我是借鉴了每个分级module都有自己的dispatch 的这种思路。不需要一个统一的config文件，而是可以分散给下面各级各module自己处理。

恰好看到canonical老大blog的新文章。很有意思。
AJAH, (ajax in action里面讲到的 以内容为中心 的模式)
也提到了jsplet.

http://canonical.blogdriver.com/canonical/index.html

经过实际项目情况的经验，我们灵活的采用ajah要比严格的采用ajax合适得多。采用ajah可以使得在细粒度控制、服务端渲染还是JS渲染、数据组装与解析等方面更容易找到平衡。

建议lz去研究下onet的纯jsp论坛，基于fastjsp，参考人家的M+V+C是如何清晰架构的。

非常赞同楼主的观点----除了“放弃frameset”，个人认为frameset/iframe还是不错的。

另外，
“只有在很特殊的一些地方，才不得不写少量的Servlet，比如download 或者write动态图像。 ”
我更彻底，只要注意适当地调用response.reset() download 和 write动态图像也可以用jsp实现。