没有简单的商业使用，一个成熟的软件就必然具有一定的复杂度。所以一个成熟的开发框架就必不可少。

　　引见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么？

　　或许你会通知我不需求同步开发或层替换或层独立变化，那你该考虑为什么选择分层了，或许分层的架构不是你想要的。:)