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中从此失效 。