WEB开发框架JACKER探讨(一)

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

介绍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么？
或许你会告诉我不需要同步开发或层替换或层独立变化，那你该考虑为什么选择分层了，或许分层的架构不是你想要的。:)

(待续...)

WEB开发框架JACKER探讨(二)

继续抛出我的观点

.WEB层和业务层解耦
WEB层是通过调用业务层来实现一次业务操作的。所以WEB是依赖业务层的实现的。如何解偶使两者能独立开发而互不影响？我倾向使用统一的调用接口：使用一个命令字符串，加一堆DTO参数就能调用业务，然后取得DTO返回值。这里一个业务的调用就是一个命令的执行。Ofbiz的service engine就是这样的做法，而且很成功，这也是一种关注业务的理念。使用统一的调用接口，WEB层的开发就可独立进行了，不用依赖业务层就能进行编译。而且这种做法还带来了更多的好处：权限，日志都能集中管理；将来可能的话，分布式部署业务层也变得方便，因为所有业务都是一个命令接口调用。


.MVC
MVC是一种设计模式，用在WEB框架中，使我们有效的对WEB层进行再分层：VIEW+ACTION
struts,webwork都是MVC框架，而webwork更是灵活优雅，令人赞叹！
熟悉MVC和接受MVC的人也越来越多。无需多说，Jacker也拥抱MVC；


.xmlhttp
从解决问题角度讲，xmlhttp很强大，你可以选择它，完全依赖它。
不过我觉得富客户端的技术，已经不是真正意义的WEB开发了，我认为服务器端生成动态页面才是真正意义的WEB开发。WEB交互的主要方式是form的post和get,而决不是xml流的post和get。况且在服务器端直接访问对象及属性总比做一次xml转化再到客户端解析出数据来的直接。当然xmlhttp作为增强界面交互能力的技术补充，还是必不可少的;
而如果你使用富客户端技术，那也未必一定要选择xmlhttp,javascript我也打了多年的交道，给我的感觉总是弱弱的，特别是调试麻烦，有时无章可寻。
下面我会说到轻量，完全的基于xmlhttp，无疑需要有个庞大的js库(后台也要有java库)的支持，感觉很重。

注：关于xmlhttp的最新看法，我打算使用get的方式处理所有数据库查询提取记录及展示数据方面的交互，而对提交修改数据库的操作，则使用xmlhttp来做，把form中的参数自动转为xml格式后post，后台使用webwork拦截器自动映射值到action属性。xmlhttp有个天然的优点：提交数据操作界面不用刷新，不用再考虑后台处理不成功后的界面数据保持问题了，所以它更适合做post数据。


.View的再分层
MVC架构中，展示层View的技术是五花八门，可选择的太多太多，jsp可能是用的最多的，模版语言也多种多样，我分为两类：脚本模版和简单模版。脚本模版如velocity,freemarker,可以在页面用方便的脚本定义变量，运算并产生输出，虽然比jsp干净了很多，脚本的嵌入多少还是影响了页面的整洁；而简单模版的理念则是将页面逻辑从模版中抽取出来，模版只是用固定的布局展示数据，保证“所见即所得”的开发效果;
简单模版的引入对View层开发将是变革性的，模版简单，页面没有任何代码污染，直接好处就是View开发的再分层，美工也能直接参与模版的开发，有助于产生专业质量的界面效果。
对简单模版的详细介绍可见我的blog:http://blog.csdn.net/goldrain/

.轻量和灵活
细分了这么多层，每一层都是有很多很多的技术框架可以选择，轻量灵活的解决方案自然更受欢迎。EJB无疑是重的，struts相比webwork则笨了点，简单模版对比脚本模版，则也轻盈许多，几乎没有语法需要学习。
Jacker能在tomcat上轻松的运行，各层的框架选择是：
view : eastm简单模板(子项目)
web mvc : webwork
业务解耦及调用 : jservice(子项目)
业务层 : spring+hibernate

.对ofbiz一些看法
ofbiz无疑是个成功的业务框架，算得上是博大精深了，我用ofbiz写过一些东西，也只是对其entity engine，service engine及mvc框架有所了解。不过还是有些不同的看法，否则也不至于在这里构思自己的框架了：
面向属性还是面向Map？
我称ofbiz是面向Map的一种解决方案，service使用map传值，entity使用map存字段值，使用key访问值。web层中,request中的参数也是直接转为map就用于传递，而不是先映射到对象的属性字段。map的方式有个好处就是可以少定义很多属性类，特别是DTO,但相对使用属性承载数据的POJO方式，map显得不够直观严谨，而且属性对象开发中IDE可提供属性方法提示,map自然做不到。我倾向面向属性为主的编程，map为辅。
组件耦合还是解耦？
ofbiz的各引擎组件耦合的很紧，很难抽取出来单独使用。entity engine,service engine,web mvc架构，工作流等都相互依赖，难以剥离单独使用。
解耦，保持组件的独立性，也就给了开发员更多的选择，可以选择使用整套方案，也可以选择部分。
(待续)

据我所知，Ofbiz 的设计很大程度上是基于《The Data Model Resource Book》卷1和卷2。我已经有了这套书两卷的中文版，不过还没有来的及看。goldrain 和论坛里熟悉 Ofbiz 的朋友（包括读过这套书并且用过 Ofbiz 的 Quake）有空了能不能分析一下 Ofbiz 和这套书的关联。

这套《数据模型资源》我没有研究过，好像是用于业务建模的
我用过的是ofbiz3.0

ofbiz的确在其引擎框架之上对组织结构，权限角色，订单等还有很多领域都参照《数据模型》做了示范性的实现。不过我觉得这些都只是ofbiz演示用的例子而已，ofbiz其实是作为一个完整的技术框架而存在的。而业务建模我倒觉得只是应用开发设计的事了，和ofbiz框架应该无关。

另外，DTO和O/R mapping中的数据对象PO(比如:Hibernate的POJO);是两回事，一个描述业务，一个负责底层数据库操作。你如果选择了分层，就不要试图用PO取代DTO传递到WEB层，自然更不需要hibernate的什么open session in view

楼主,这段话,我感受颇深啊~~,我想这就是DTO的作用吧~~~既可以把web层分离开,也可以把后台调用的业务层分离开啊~~ :P 

是的，层次就通过DTO给分开了。

clap~~

不是待续么，go on 亚

注：关于xmlhttp的最新看法，我打算使用get的方式处理所有数据库查询提取记录及展示数据方面的交互，而对提交修改数据库的操作，则使用xmlhttp来做，把form中的参数自动转为xml格式后post，后台使用webwork拦截器自动映射值到action属性。xmlhttp有个天然的优点：提交数据操作界面不用刷新，不用再考虑后台处理不成功后的界面数据保持问题了，所以它更适合做post数据。


我也在考虑这样组合。 不过有个疑问是，xmlhttp这么强大了，为何还要再用ww2来多此一举。可以直接用xwork就够了？

当然我这样的组合是，当某个时候发现xmlhttp实现不了某个功能，直接就用ww2搞定 呵呵呵

xmlhttp再强大view还是要有的呀