为什么 Ofbiz 没有使用 Struts

目前开源的开发框架很多，大家完全没有必要把目光全部集中于 Struts。Struts 中的 MVC 设计也不是最好的。
以前学习 Ofbiz 的时候看到过老戴（Ofbiz 的总设计师 David E. Jones，我们都这样叫他）发的一篇帖子说明 Ofbiz 为什么不能直接使用 Struts。今天找了找，应该就是这篇了：
http://www.geocrawler.com/archives/3/12465/2002/3/100/8002721/
如果想要学习框架的设计，Ofbiz 是一个非常好的起点，它是真正面向企业应用（面向业务的，而不是纯技术的框架，纯技术的框架是没有多大价值的）而设计的，而 Struts、Turbine 等框架对于简单的 Web 应用还可以，但是对于复杂的企业应用就显得太单薄了。企业应用的问题并不是靠简单地分出 MVC 就可以解决的。
Ofbiz 中文网站：
http://www.ofbizchina.com

老戴基本上没有对 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。

To:无明

你这段话，句句到说到我心里面了，你这些话，其实也就是我想说的。
非常非常赞同你的观点！加入精华了。

无明兄，我很同意你的观点。你对框架作用的描述比我要清楚的多。J2EE 确实只是对低层次的逻辑进行了抽象和建模，做的还远远不够。这也是我对 EJB 由热衷到冷静到失望的原因。我接触过很多朋友对 EJB 还有 MVC 都不是非常的热衷。但是对于初学者，往往最喜欢谈论的就是 CMP 和 MVC。我写了很多反对的意见，并不是说它们没有价值，而是它们完全没有达到 Marketing Hype 所描绘的理想境界。在我看来，企业花费巨资购买一个仅仅实现了 J2EE 规范的 WebLogic 是完全没有价值的，因为没有解决任何的业务问题。当然有人会反驳说一分钱一分货，我只是觉得 Java 技术发展到了今天，完全有性价比更高的选择。J2EE 把对业务进行建模的任务完全甩给开发者，这是一个很大的问题。因为开发者完全不清楚需要把哪些业务对象表示为 Servlet，哪些表示为 Session Bean，哪些表示为 Entity Bean，即使发明了那么多的 Patterns，如何对业务建模仍然有很大的难度。业务建模的复杂程度要远远超过对连接池这样的简单对象的建模。随着软件技术的成熟，软件开发者关注的领域越来越向问题域转移，这也是为什么最近 AOP 兴起的原因。AOP 是直接关注问题域的新型开发方法（当然 AOP 是不能够脱离开 OOP 的，它是 OOP 的最新发展）。

在我们看来，今后几年国内的企业对于面向业务的开发框架的需求将呈现一个快速的发展阶段。我们希望自己在这个市场占有一席之地。我们希望自己将来成为框架的设计者而不是一个纯粹的使用者。这样的业务框架设计的难度比设计一个纯技术的框架要高的多，因为你必须有多年大型项目成功实施的经验，对某一行业的业务非常熟悉之后才能够设计好。设计一个框架不难，设计一个真正有用的框架就很难了。IBM 也没有什么象样的框架，所以只能拿开源的东西直接来用（WebSphere 中有多少东西都是来自于开源软件）。IBM 是在帮助开源社区，但是他拿走的也不少。

我觉得你对 ejb 的理解有些偏差，ejb 的核心是什么？我想应该是tp monitor，而不是什么 cmp & bmp 。
只有了解什么是 tp monitor ，才能确切知道 EJB 的价值。自从60年代tp monitor 软件（cics）出现后，在商业领域一直没有能够出现 cics 的竞争者。而tp monitor 软件的市值之大另各软件公司所垂涎（500强企业中95%以上使用cics）。而传统的 TP monitor  软件是面向过程的，所以在面向对象的语言出现后，如何实现面向对象语言的事务控制一直为工业界所关注，EJB 的出现可以说另业界兴奋不已，这就意味着企业的核心软件终于可以用先进的面向对象的语言来编写了。但是很遗憾，ejb 还是不太成熟，所以直到现在，（大）企业的核心软件仍然由cics所盘踞（部分原因是大机的缘故）

为什么tp monitor这么受重视呢？
非常简单: 是因为企业的软件过于复杂，交易量太大而且事务交易过程决不允许出错！真正能够达到工业强度的 tp monitor 软件，你的选择基本上很少，而能够用在大型机上的 tp monitor ，基本上你没有选择，而价格更是让你咋舌！而业界对这个东东也是恨之入骨(有如微软)。

你说的有些道理。但是大量的应用不一定要用到 EJB 的跨数据库两阶段提交，它们可能只需要用到 JTA 所提供的功能就可以了。在涉及到跨数据库两阶段提交的场合（比如银行的转帐业务），我确实还不清楚有比 EJB 更好的选择。CORBA 比 EJB、WebService 都要成熟，然而它缺少的正是一个 TP Monitor，而 EJB 以规范的形式实现了这样的一个 TP Monitor，确实减轻了很多的开发工作量。而且我相信业界主流的 Java 应用服务器在高可用性方面完全可以满足重负荷业务的需求。在分布式应用，尤其是涉及到大范围的事务处理的场合，我相信 EJB 是目前最好的选择。然而对于一般的信息管理系统，EJB 确实有些过于重量级了。
EJB 属于框架的范畴，任何一种框架都有其适用和不适用的场合，抛开具体的应用领域来谈其优劣都是不适当的。我还看到过有人认为“工作流必须要用 EJB 来实现，否则是无法想象的”这种说法。“有了一个锤子，看到什么都是钉子”这是我看到这种说法后直接想到的第一句话。

我想我们说的都有一些道理，但是应该加一些限定，否则就变成无边际争论了。在我们的开发领域，确实看不到很多必须要使用 EJB 的理由。我也并不认为做分布式应用就一定比设计 MIS 系统要高级，大家各有各的难处。

在金融行业的核心软件里面，基本上没有跨数据库的 tp monitor 。
tp monitor 监控的是应用软件可能出现的异常，脱离了tp monitor， 程序员没有办法100%的保证没有差错！ 实际情况是，软件中99.9%没有问题，而tp monitor 控制的是那个 0.1% 的异常。
java 提供了很好的异常控制，但是能不能100%的捕获异常并做出正确的处理呢？而且要保证每个程序员都不能出错。 这个问题才是关键。

这类银行的核心应用正是我说的少量应用。你不能让所有的人都跑去做银行应用吧？就银行这样的关键应用而言，不用 EJB 确实很难达到高可用性的要求。我们做工作重要的是要站在巨人的肩上，EJB 是一个巨人，但是它也不是不发展了。光是说“EJB 就是好来就是好”（有点象脑白金的广告）而看不到它的局限性是要犯错误的（别介意，我没有特指）。EJB 确实做了很好的工作，但是如何更方便地对数据做复杂的加工处理却是 EJB 没有解决好的问题（这正是我说的 J2EE 甩给开发者来解决的问题），要由 Hibernate 等面向数据建模的框架来解决。实际上 Hibernate 解决的也是局部的问题，研究 Hibernate 应该放到企业数据流的大背景下思考才能把 Hibernate 的优势充分发挥出来。开发者现在需要的不仅仅是 EJB 这样解决了关键技术问题（比如 TP Monitor）的框架，他们还希望得到一个能够帮助他们解决业务问题的业务框架。不知道你有没有真正理解我说的话，解决技术问题是不值钱的（尤其是在 JBoss、JOnAS 等 Open Source 的应用服务器出现后。Java 应用服务器市场已经是一个过度竞争的饱和市场），解决业务问题才是值钱的。位于产业链的高端的企业才是最舒服的，这也是我们将来的发展方向，我们会在将来适当的场合采用 EJB，关键是看是否有这方面的业务需求（分布式的应用，对事务处理的高可用性要求很高）。

真的不明白！
tp monitor 顾名思义，就是一个事务监视吗。哪里会替你进行数据加工呢？数据处理还是要靠程序员用 jdbc 来操作的呀。Hibernate 是提供了一个数据访问的高级封装，你可以用，也可以不用，而且Hibernate 也不是万能的，很多情况下不还是要靠 jdbc 去解决吗。
EJB是一个框架吗？没有体会。什么是解决业务问题的业务框架？搞不懂。
For Example?