日期:2014-04-06  浏览次数:20680 次

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

  介绍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么?

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