没有简单的商业应用，一个成熟的软件就必然具有一定的复杂度。所以一个成熟的开发框架就必不可少。
介绍JACKER之前，先抛出一些我的观点，这些观点有的是我在多年的开发积累中形成，更多则是来自javaeye，在这里我也发过一些贴子，但看贴居多。有时我真的觉得技术积累还不是最重要的，最多让你成为一个熟练的技工而已。最重要的是思想，理念的交流，以及溶入自己的思考。
我有幸在论坛中看到了很多开发理念的争论，在翻阅这些贴子的同时，自己也不知不觉的就有了立场：
.分层开发
分层开发带来的直接好处就是关注点分离，每个开发只要专注于自己一层的开发，是开发专业质量软件的起点。
没有一个开发会是全才，即使你了解每一层的开发技术：
html+css+javascript,java:struts+spring+hibernate,xml等等，你敢说你精通这所有的技术么？我做了五年的开发，接触了很多，算是很有经验了，但坦白讲，自己对html,css始终没有太多兴趣，javascript的掌握也只有所侧重，用javascript实现一个时钟或独立完成一个javascript树对我来说简直就是不可想象；hibernate也只关注单表的配置和操作，其他地方没时间做深究;xml操作则是了解了下dom4j的一部分，什么xpath因为用不着就没看;
没有全才，全才也不能这么用。让他从头到尾从界面到数据库的实现一个软件模块的每个编码细节，这是对软件质量的犯罪。“全才”开发员的水平也有高有低，技术偏重也各不相同，一人一杆子捅到底的做法，后果就是一个系统里的各个模块质量参差不齐，界面风格难以统一，代码混乱，公用配置文件并发冲突严重...
所以开发要分层，WEB开发首先要分出WEB层，业务层，而WEB层还要用MVC架构再细分;
分层的开发需要分层的架构，分层的框架也强制要求分层的开发。你如果坚持一人包办一个模块的做法，那我觉得你还是采用jsp+javaBean的做法更合适，别选择分层架构了，让一个人在各层间跳来跳去，会头晕的;
分层开发的一个难点是管理，如何分配任务和各层集成调试给管理者提出了较高的要求。这是另一个话题这里就不多说了。
.DTO，WEB层，业务层
DTO就是Data Transfer Object,数据传输对象。DTO主要负责client(WEB层)和业务层的数据传递。DTO简单的就是一些Java类型，比如:String,Integer,甚至List,Map等，更多就是POJO了，用属性承载数据。虽然只有属性的DTO被一些大师如Martin Fowler认为是“贫血的”，但我认为DTO很好的履行了它的职责：描述业务接口，传输业务数据。从调用业务层的角度，我把DTO细分为传参PDTO和返回值RDTO。有属性的DTO也从数据角度很好的描述了业务。所以DTO是必不可少的;
DTO有效的隔离了WEB层(调用层)和业务层，现在还有“贫血的”和“不贫血”之争，我觉得使用“贫血”这样的字眼有扣帽子之嫌，我更愿意称这样的DTO为简单DTO,简单DTO坚持了一个我认为必须坚持的原则：层次分明，不把业务逻辑扩散到WEB层。分层的目的不就是分离逻辑么，怎么WEB层还能访问有业务逻辑的对象？包括业务常量，都是WEB应该杜绝访问的。而显然“不贫血”的DTO不打算这么做;
“简单即是美”，DTO也是。
另外，DTO和O/R mapping中的数据对象PO(比如:Hibernate的POJO)是两回事，一个描述业务，一个负责底层数据库操作。你如果选择了分层，就不要试图用PO取代DTO传递到WEB层，自然更不需要hibernate的什么open session in view。原因很多：
分层带来的一个好处是同步开发，甚至WEB层可以先于后台业务而实现，只要业务接口定义好并且业务层有了模拟MOCK实现。试想数据库还没建立时，你的PO从何而来，又怎么能传到WEB层去？
分层带来的另一个好处是各层的可替换，和可独立变化以应对变化的需求,而DTO作为描述业务接口的对象类型应该是相对稳定的，这种要求下，可能某天你的业务层操作不用hibernate而使用ojb了，你还能坚持使用hibernate的PO来描述业务接口？或者你的O/R永远不变，但频繁的数据库的重构导致你的PO一改再改，你还敢用PO去取代相对稳定的DTO么？
或许你会告诉我不需要同步开发或层替换或层独立变化，那你该考虑为什么选择分层了，或许分层的架构不是你想要的。:)