继续抛出我的观点
.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库)的支持，感觉很重。
.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架构，工作流等都相互依赖，难以剥离单独使用。
解耦，保持组件的独立性，也就给了开发员更多的选择，可以选择使用整套方案，也可以选择部分。
