下面是我对J2EE标准分层框架的一点理解，但在实际使用中，觉得这个分层太复杂了，不适合快速开发。而且项目小组成员的技术能力不同，应根据小组成员的技术情况来选择合适的技术组合（比如以前接触到一个项目，项目组成员很多都是其他语言转过来，对数据库相当熟悉，对JAVA不算熟悉，这时我就将JAVA层处理工作减少，让其他成员去关心数据库存储过程实现业务逻辑，而JAVA层只做前台与数据库的沟通）。我会在后面的BLOG中再讨论简化框架。

 （晕，为啥我提交不上图片呢？）

RDBMS：这个就不说了，后台数据库。

持久层：用于将JAVA对象与DBMS二维数据映射处理，现在常用的框架有Hibernate和Ibatis，我会在后面的BLOG中详细介绍两种方案的差别和使用，以及介绍其他OR方案。

业务逻辑：业务逻辑是一组完成业务操作，这个业务操作可能只有一个DAO操作，也可能是多DAO操作、以及其他操作的集合。

前台MVC框架：MVC的思想就是将控制、模型、显示分离。STRUTS是一个比较好的早期实现（我看过一个JSF软件，SUN的creator 2.1，觉得JSF实现也挺不错的，可惜一直没时间去学习研究）。其实个人认为，如果项目组成员较少，且前台技术较好的话，可以不用STRUTS，直接用JSP，因为STRUTS是增加了工作量。我会在后面专门讨论下前台MVC这块。有兴趣的请关注或联系我。

HTML/JS/HTC显示层：作BS开发这么久了，其实我觉得这一块是最不好把握的一块。而且项目组成员的技术差异也特别大。这一块我是专门花大时间来维护框架及常用功能。尽量减少其他人员来写一块，目前效果还算可以。我会在后面BLOG中讨论前台框架，欢迎关注或联系我。

AJAX：现在比较流行，但实际技术东西很少（用不超过二十行的代码就能完成说明AJAX的用途），在某些时候很有用（比如收费界面）。同样，具体内容以后再单独讨论。

总之，我认为最重要的一点，框架是为了更快更好地完成工作，不能为了框架而框架。框架的分层、技术选择应根据业务需求、项目组成员来选择。客户并不关心你用了哪些先进的框架，不关心你如何去具体实现的。