为什么 Ofbiz 没有使用 Struts

主要原因是 Struts 的设计与 Ofbiz 的设计有较大差别,因此很难无缝地集成进来。而老戴以为以自己的能力,写一个 MVC 框架是件很容易的事。所以在 Ofbiz 中,MVC 框架、OR Mapping 全部是自己设计的。老戴的一个基本思想是通过 XML 对系统进行建模,以 XML 来定义系统中不同的层次关系,尽量减少写 Java 代码的数量(甚至创造了一套以 XML 为基础的 Mini Language 来做一些简单的逻辑处理)。而在 Struts 中仍然需要写大量的 Java 代码。Struts 在减轻开发人员工作量方面做了一些努力,但是做得还不够(甚至带来了额外的复杂性,我认为 Ofbiz 的表示层比 Struts 更容易理解)。如果说面向对象开放框架的目标就是实现更大程度的代码重用的话,无疑 Ofbiz 在这方面要比 Struts 更成功。

根据我的使用经验,Ofbiz 中的 Event Handler、Service、和 Entity Engine 的设计是非常灵活的。确实极大地减少了 Java 代码开发量,换之以更多的 XML 配置文件,但是这个工作量要比做 Java 开发小得多。

某种程度上,Ofbiz 和我们现在设计的这个框架有很大的相似之处,我们都是面向业务问题的框架而非学术性的纯技术框架。

这里是不是牵涉到一个如何对待技术框架和业务框架的问题?

按我的理解,框架技术实际上就是流程固化技术。在框架技术中应用的很多的一种就是回叫机制(callback),对比MFC之类的东西,框架其实就是由设计好的工作流程调用具体的数据结构和算法(在C/C++中使用函数指针,Java中使用接口)。

J2EE我更多的是做为一个框架来理解,而不仅仅是一组API。J2EE面对的问题域主要集中在分布式计算,那么它就固定了一套处理分布式计算的流程。我把它看作一个技术框架,它处理的流程是面向机器的:如何定位资源;如何管理连接;如何传递消息;如何处理事务;如何处理安全等等,这是所有业务的基础。所有的商用逻辑最终都是要转换成这些计算逻辑。

从这个角度看,实际上 J2EE的抽象级别还是相当低级的。程序员的作用就是把商业逻辑转换分解为计算逻辑。随着程序的变大,人们自然的想在技术框架上再做一次抽象,把商业逻辑向技术逻辑转换的流程固定下来,这样就可以大大减轻开发的负担。

这样就要求设计者对商业逻辑和技术框架都相当了解,才能完成这个抽象。–谁说软件开发变简单了?

在这个趋势下,程序员的两极分化必定越来越大,一方面向框架的设计者集中,一方面向框架的使用者集中。各种各样的框架也会越来越多。

优秀的开发者会根据合适技术建立适合自己业务的框架,而不是盲目地追逐现有的热门的框架。

stuts主要是面向Web开发的,而真正的企业应用的UI层是很薄的(dlee,这是你说的哦:) ),或许,是这个原因ofbiz没用stuts。