1 使用OFBIZ的理由
1.1 什么是OFBIZ
OFBIZ是由Sourceforge维护的一个最著名的开源项目之一，提供创建基于最新J2EE/XML规范和技术标准，构建大型企业级、跨平台、跨数据库、跨应用服务器的多层、分布式电子商务类WEB应用系统的框架。OFBIZ 的Web应用框架以MVC模式搭建而成，整体采用了很多被大多数企业级应用系统公认的位于业务逻辑层和集成层（Business Tier and Integration Tier）的设计模式。许多表示层（Presentation Tier）的设计模式也被引入进OFBIZ，但是仅仅体现在Servlet控制器（the servlet controller）中,没有包括在实体引擎中。在实体引擎中使用的设计模式包括：业务代理（Business
Delegate），值对象（Value Object）， 复合实体（Composite Entity(variation)），值对象组装器（Value Object Assembler），服务定位器（Service Locator）和数据访问对象（Data Access Object）。OFBIZ正在计划逐步引入其它设计模式和完善已经引入的设计模式的实现。使用OFBIZ的框架和组件，可以大大缩短开发企业级WEB应用系统的进度和成本。了解详细情况请参见：http://sourceforge.net/project/ofbiz 1.2 OFBIZ和其它项目的比较
与ofbiz 类似的项目还有很多，ofbiz与这些项目的最主要的不同点是ofbiz提供了一整套的开发基于Java的web应用程序的组件和工具。一个优秀的web 应用程序应该是至少三层结构：表示层，业务逻辑层和数据层。大多数应用框架，比如Struts, Cocoon, 和 Velocity 将主要精力都集中在了表示层。比如Struts，遵循了(MVC)构架，使用Java Bean和Action类与JSP页面进行通讯。Struts是一个很好的web应用框架，但它并没有提供访问数据库的组件，也没有提供控制工作流的组
件。如果要使用，你必须自己创建这些组件。如果已经在利用其它的应用框架（如Struts），你也可以很容易的将ofbiz的组件添加到自己的工程中。与其它类似开源项目相比，OFBIZ是一套有血有肉的包含编译打包部署工具、应用组件、示例应用等内容的企业级Web应用系统实现框架。1.3 开源的优势
OFBIZ是一个开源项目，由几个牛人在维护，它具有开源项目的一切优势，如免费（随时下载）；集市式开发方式；成千上万的人在维护，也在测试等等。也具备开源项目的所有缺点，如缺乏技术文档，提交的系统没有全面测试；不稳定等等，但无论如何，我们要清醒的认识到：1、 OFBIZ是一个开源项目。2、 OFBIZ只仅限于系统开发者使用。1.4 完善的实体引擎
OFBIZ 实体引擎提供了一组工具和设计模式来对现实世界中特定的实体（数据对象）进行建模和管理。在本系统的上下文环境中，一个实体就是一个由多个数据域 （fields）和该实体与其它实体之间的关系所组成的一个数据对象。这个定义来自于关系型数据库对实体关系模型（Entity-Relation modeling）概念的标准定义。实体引擎的目标是简化企业级应用中对实体数据（对应关系型数据库表）的大量操作，包括定义、维护、通用操作（增、删、
改、查实体和实体之间的关系）的开发工作实体引擎采用了很多被大多数企业级应用系统公认的位于业务逻辑层和集成层（Business Tier and Integration Tier）的设计模式。许多表示层（Presentation Tier）的设计模式也被引入进OFBIZ，但是仅仅体现在Servlet控制器（the servlet controller）中，没有包括在实体引擎中。在实体引擎中使用的设计模式包括：业务代表（Business
Delegate），值对象（Value Object）， 符合实体（Composite Entity(variation)），值对象组装器（Value Object Assembler），服务定位器（Service Locator）和数据访问对象（Data Access Object）。OFBIZ正在计划逐步引入其它设计模式和完善已经引入的设计模式的实现。实 体引擎的一个主要目标是尽可能的提供一种通用的代码结构，来消除在针对每一个实体的事物处理过程中，所有写死（hard code）的代码。 这种系统抽象所关注的问题，与那些把数据从数据库中提取出来，并以报表的形式进行输出和显示处理的报表管理或类似系统是不同的，而是类似于每日都可能发生 很多事物处理的商业应用系统，实体引擎能大量节省构建类似应用系统的开发费用和戏剧性的减少因为系统存在大量写死的事务处理代码所产生的bug。这种类型
的应用系统目前在OFBIZ中实现了一些，如电子商务，入库、出库的帐目管理，任务分配资源管理等等。这些工具能够用来报告和分析系统，但是并不意味着， 它能包容千差万别的客户的应用需求，在实际应用中，我们可以基于它来做一些二次开发。为了达到尽可能少的在系统中出现与针对特定实体操作有关的代 码， 存储实体属性值的对象结构必须设计成通用的，可以用一个MAP对象来存贮实体的所有域（也可以叫字段或属性），通过实体的名称来区分它们是哪个实体的。根 据字段的名称，用一个简单操作String数据的方法，来从值对象中读出或写入某字段的值，并且还可以验证给定名称的字段是否是该值对象的一个合法域。在 实体引擎和应用系统之间建立了一个约定（体现实体结构定义文件和字段类型、Java数据类型、SQL字段类型映射关系的定义中），这个约定被定义在特定的
XML文件中，以减少这种灵活性可能存在对系统不利的风险（如数据类型问题可能引起数据库系统崩溃等）。代替不在系统中书写针对特定实体操作的的 代码的方法之一，是把实体的定义放在XML文件中，在系统启动的时候，由实体引擎负责把这些结构定义加载进内存，并且在应用程序和数据源（通常指一个数据 库或其它资源）之间建立一些对这些定义的使用规则。在这些XML实体定义中，对实体和属于它们的域，以某种规则和数据库中的表和表的字段建立映射关系。而 且实体与实体之间的关系，实体域的数据类型，Java语言的数据类型，SQL
数据类型之间的映射关系，也被定义在XML文件中。 实体之间的关系还可以被命名，以用来区分不同实体组合之间的特定关系。基于实体引擎这个抽象层，与特定实体操作有关的代码的编写就变的很容易创建 和修改。 使用实体引擎所提供的APIs，编写处理实体持久性（增、删、改、查）的代码，可以不同的方式来配置，以便于实现针对实体持久性操作（增、删、改、查）有 变化时，可以不改变代码本身，因为它并没有写死。这种抽象的一个典型应用场景就是你既可以通过JDBC直连方式，也可以通过调用运行在EJB服务器上的实 体Bean（Entity
Beans）的方式或者以其它方式，甚至在系统所提供的框架范围内，使用者运用自己扩充的方式去完成对实体持久性的改变等等。这些不同方式的切换并不需要 对代码做任何改动，只需要修改配置文件。OFBIZ已经完全实现了自己设计的一套实体引擎，可以直接使用。project/ofbiz实体引擎的好处举例说明如下：以前的问题背景。1、 你需要借助工具或手工去维护已经存在的或新增加的数据库结构（库结构，表结果等的定义和更新），如果要修改表结构和定义的话，怎么做？2、 假设你的应用涉及200张表（实体），假设每张表（实体）都存在增、删、改、查，则需要在你的应用中静态构造（硬编码）800个sql语句。3、 假设这200张表之间存在100种关系，维护每一种关系的增、删、改、查，又需要400个静态构造的sql语句。4、 假设这些sql语句由10个不同水平的程序员来构造，构造出来的sql语句在执行性能上可能存在巨大差异，而且形态各异。5、 这些硬编码的sql语句分布在大量Java程序的各个角落，一旦某张表的结构发生变化或者修改某一字段名或表名，意味着什么？意味着混乱！OFBIZ是如何解决这些问题的：OFBIZ拒绝这种混乱，一套EntityEngine机制轻松解决上述所有问题。1、 涉及1张表（实体）的增、删、改、查，它提供一套处理机制（不到12个类，大约5千行代码），应用的规模是10000张表，它还是这套处理机制（不到12个类，大约5千行代码），而且这些处理机制由JAVA程序高手生成和维护，可以保证其合理性、可靠性和安全性。2、 EntityEngine提供了一个构造复杂sql操纵语句的机制，你可以根据需要随时构造任意复杂的sql语句，完成你想要做的事情，这样你可以在开发过程中，随时修改你的数据库定义，OFBIZ在系统启动时会自动加载并检测数据库中的不一致性和参考完整性。3、 实体引擎大大简化了涉及关系型数据库的管理和维护，但这还只是一小块好处，大的好处是你在实现一个复杂需求的应用时，实体引擎用为数不多的几个类解决了你所有的问题，实现任意复杂的数据库存取业务和商业逻辑，而且与需求的复杂度和数量无关。4、 好处太多了，在使用的过程中，会进一步的体会到。1.5 锦上添花的服务引擎
服 务框架（Services Framework）是OFBiz2.0 新增加的内容。服务（Services）被定义成一些相对独立的逻辑处理单元（服务具有业务逻辑处理的原子性），能够被灵活的组合成不同的形式去实现不同 的商业逻辑需求。服务有多种类型的实现形式：工作流（Workflow）,（规则） Rules, Java程序（Java）, 简单对象访问控制协议（SOAP）, 轻量级Java程序脚本语言解释器（BeanShell）等等。
如果一个服务被定义成"java"类型，意味着实现该服务的机制可能就是Java类的一个static方法, 而且，OFBIZ提供的服务框架不限于使用在一个基于Web的应用程序系统中。服务需要输入一个Map形式的参数，服务处理完毕后，返回的也是一个Map 形式的结果集。这个思路是非常好的，因为Map类型的数据格式很容易被序列化（serialized，序列化成字节流），并且通过HTTP(或SOAP) 的协议进行存储和传输。在OFBIZ里，服务被定义XML文件里，定义后的服务被分派给一个特定的 服务引擎（Service
Engine） 。 服务引擎 具体负责以合适的方式进行服务的定义、管理和调用。 因为服务不一定被绑定在某基于Web的应用程序运行环境中，所以服务处理的结果也就不一定会和某erquest请求的响应reponse联系在一起，这样 就允许服务可以在预先设置好的和时间点上定时触发（因为它不需要一个Http Request请求），一般是通过系统提供的 工作日程管理器（Job Scheduler） 运行环境触发（用定时器来控制对服务的调用）。 服务还可以互相调用调用，即一个服务被设置去调用任何其它的服务。这 样，我们可以用更小粒度的已经定义好的服务组合成一个服务链，来完成一个比较大的任务，而且这种组合是任意的，从已经定义好的服务本身来讲，是很容易复用 的。使用不同的应用程序系统中的服务，可以通过创建一个"全局服务定义文件"只被定义一次（因为服务本身是实现了特定的商业逻辑，它和具体应用的关系应该 是松耦合的），当然，服务也可以通过一些限制，被指定为特定的应用程序所用。 在一个基于Web的应用系统中，服务可以被用来实现基于Web的 事件（web events）,利用服务实现事件处理，可以在服务框架内最大可能的复用相对固定的一些业务逻辑。而且，服务还可以被定义成对可输出的 （exportable），意思是它们可以被系统外部的东西（可能是一个应用系统或其它）远程访问。 目前系统实现了一个基于简单对象访问控制协议（SOAP）的事件处理器，该事件处理器，就允许外部应用通过SOAP协议对运行（或定义）在其上的服务进行
远程访问 。在将来，会有更多的远程调用形式被加到服务框架里1.6 双管齐下
实体引擎和服务引擎各有利弊，在实际应用中，可以把服务引 擎和实体引擎结合起来使用，实体引擎主要用于处理实体（Entities）对象的增、删、改、查，服务引擎主要用于处理商务逻辑，这种商务逻辑的定义范 围，不大会遇到上面所说的要求一次查询返回一个结果集这样的服务定义（这完全可以用实体引擎来处理）。服务引擎可以用处理跨平台、跨操作系统、跨应用系统之间的业务逻辑。把实体引擎和服务引擎结合起来，可以这解决企业级Web应用系统的绝大部分需求所涉及到的技术实现细节。1.7 其它甜饼
OFBIZ的野心太大，几乎想通吃所有最新的关于企业级、多层、分布式应用系统的构建技术。除最成熟的实体引擎和服务引擎之外，它还涉及到以下系统实现引擎。1、 工作流引擎2、 规则引擎3、 消息引擎这三项工作，除工作流引擎尚为alpha版本之外，其它两个都在建设之中，看来，已经把这几个人累的够呛。1.8 主流技术的采用和跟踪
OFBIZ 的框架中引入了最先进的主流开发技术Web应用系统构建技术，如：Xerces (xml.apache.org) ；Xalan (xml.apache.org) ；Axis (xml.apache.org) ；Log4J (jakarta.apache.org) ；Castor (www.exolab.org) ；ORO (jakarta.apache.org) ；BeanShell
(beanshell.org) ；J2EE1.3，XML1.2等，而且整个系统，在原来的基础上不断的被重构和修订。1.9 扩展性和可移植性
OFBIZ 所提供的系统框架，是一个纯Java的应用程序，在具体实现中采用了大良的设计模式，本身系统的实现完全符合面向对象的设计原则中的几乎所有要求，除采用 J2EE核心设计模式、数据库设计模式之外，OFBIZ的实现代码中，大量引入和Java设计模式，其应用系统本身的扩展性和可移植性已经没有问题。OFBIZ开发者同时维护和Weblogic，Tomcat，Jboss，Resin，orion等16个厂商的Web和App应用服务器的兼容版本.OFBIZ开发者同时维护和oracle，Mysql，Sybase，PostgreSQL，Hsql等数据库产品的兼容支持，包括编译、打包、部署到这些数据库产品或应用服务器产品的运行环境下。OFBIZ开发者同时在Unix和Windiws两大操作系统上进行开发和测试，而且具备Java应用系统的所有跨平台的特点。有了这些，对于大型企业级应用系统的具体、特定实现来说，你有信心实现所谓的“一次开发，到处运行”。1.10 改进的事务处理功能
目前OFBIZ提供4种数据库连接方式的支持（在“EntityEngine.xml”文件中配置，被“EntityConfigUtil”类装载进内存）。用在：GenericDelegator ——> GenericHelper.GenericHelper ——>GenericHelperDAOGenericHelperDAO ——>GenericDAOGenericDAO ——> SQLProcessorSQLProcessor ——> ConnectionFactory类的get Collection()方法得到数据库连接。然后构造PrepareStatement来实施数据库操作。OFBIZ2.0 改进了GenericDAO和SQLProcessor，综合利用JDBC的事务管理和应用服务器的事务管理功能实现多层分步式事务管理功能，因为不同的 实体操作可以对应不同的实体引擎（在EntityEngine.xml中通过实体所在的组了配置），这样可以在OFBIZ的主运行环境下，通过实体引擎的 配置实现对远程数据源的访问操作，而一旦连接上远程数据源，OFBIZ就提供一套机制，把针对本地和远程数据源的操作纳入到同一事务管理范围内，实现分布
式事务处理。OFBIZ利用JDBC提供的数据库操作事务管理API（commit，rollback等）和第三方工具所实现的数据库操作事务管理API，实现了OFBIZ的实体引擎对事务的控制。2 不使用OFBIZ的理由
2.1 系统过于庞杂
确实如此!!它用到了XXX，XXX，XXX标准，体现着XXX，XXX，XXX技术，维护着诸多的概念、理念、包含着这么多的设计模式，光配置文件就有30个之多，涉及到的配置项不下200种，它要用到很多工具，这一个理由足以让大多数人望而却步！OFBIZ太复杂，把基础、公用的东西和特殊应用混到一块，特别在实体定义的时候（考虑关联关系）。2.2 夸夫追日
如 果把OFBIZ比做太阳的话，使用OFBIZ的人就是夸父，因为一旦你采用了OFBIZ ，它就会诱惑你，永远跟踪下去，和其保持同步，和它保持同步的同时，意味着你必须不端的充电，和XXX，XXX，XXX规范保持一致；和XXX，XXX， XXX标准保持一致；和XXX，XXX，XXX工具保持一致，这样你会很累，那有我用JDK写的东西维护起来的轻松？可是纯粹使用JDK，你又能写出什么东西？2.3 它不适合我的应用规模
的确如此，你如果是开发一个。。。。，或者。。。。或者。。。。这都用不上OFBIZ，OFBIZ是用在什么规模上的（大家自己领悟吧）。2.4 关于自带的应用
OFBIZ自带的应用，美国化的东西太多，应用背景和我们差距太大。除用户管理，系统维护，知识管理几大块之外，其它的基本上用不到。2.5 它有bug?
祝 贺你，你竟然发现了OFBIZ的一个BUG，但这是开源项目最为常见的一个问题，你可以想想，再回头看看“开源项目的维护方式”，这些BUG本身就是希望 你发现并改正（或提修改建议）的，所以BUG不是什么大事。在使用开源项目，来缩短开发周期和降低开发成本的应用前提下，更需要一种“杨弃”的理念。2.6 它连个论坛都没有?
OFBIZ的开发者没想到企业级应用关注的却是一个论坛？这不是他们关心的内容，而且你完全可以利用OFBIZ提供的一切，迅速构建一个论坛（前提是论坛的需求必须清楚）。2.7 其它理由
考虑一下，OPENSOURCE的东西可能存在其它问题，如版权问题？协议问题等等。这好象对于我们来说，并不是问题。3 简化OFBIz2.0
本着实际应用的目的，我在OFBIZ最新版本的基础上，进行了简化，主要包括如下措施。3.1 数据模型改造
1、 数据模型只保留：common，content，party，security。2、 改造所有实体定义文件，把DTD包含在每一个文件里。3、 首先整理entityGroup.xml文件，确定将要删除的实体定义，包括保留的数据模型包和在保留的包中删除不需要的，如下：（1）common和security没动。（2）content，保留大部分内容（如文档管理，支持网站统计的实体等，其它的删除），删除content.preference，content.subscription，content.website。（3）party。删除一部分和party无关的实体模型定义，如party.agreement，party.communication，party.need等。4、 根据删除的实体名称，查询确定被删除的实体所有的关联（包括实体和基础数据定义，java文件,jsp,xml,properties文件中出现这些实体的地方，逐一进行清除和改造）5、 修改entityengine.xml，删除加载的实体定义文件（eccomerence里）6、 删除加载的与应用有关的服务定义文件。7、 修改serviceengine.xml，删除加载的与应用有关的服务定义文件，删除加载的基础数据（与应用有关的）。3.2 删除特殊应用
1、 删除accounting；catalog；ecommerce；facility；marketing；partymgr；workeffort应用及 与应用有关的存在于core和commonapp里的程序文件。commonapp/src目录下只保留：common，party，content， security。如果有类似被删除应用的应用背景，再考虑引进。2、 修改setup/ofbiz/build.xml文件，把这些特殊应用有关的内容全部清除，把images应用从ecommerce应用里移到content应用里。3、 修改setup/catalina41/conf/server.xml文件。4、 修改部署环境，保留目前ofbiz支持的最好的部署环境：bea,jboss,resin,catalina41.其它以后再说。3.3 简化后的系统
其实简化后的系统， OFBIZ的内核并没有动，只是把它自带的应用全部删除（包括和应用相关的一切痕迹），但保留下来了常用的应用1、 内核管理系统——Commonapp应用。2、 用户管理——PartyMgr应用。3、 知识管理——Content应用。4、 系统维护工具——WebTools应用。精简后的内核框架具备如下功能（1） 全面支持EntityEngine，ServiceEngine；workflowEngine。（2） 支持用户管理，权限管理，知识管理（信息发布就是小意思了），联系方式管理，还具备一些通用基础数据的定义和数据本身。这是我们目前所面临或即将面临的大多数“基于J2EE/XML技术的多层、分部式企业级Web应用系统”所必须具备的功能。简化或的框架可以作为我们开发自己应用的一个原始内核。在该原始内核的基础上，可迅速开发和部署我们自己的应用。这个和适用于培训体系的OFBIZ版本的研究不冲突，可同时进行。简化后的好处，直接体现在系统规模大大减少，系统外观复杂度大大降低，系统中我们琢磨不定的东西，但可能永远都用不上的垃圾基本被清除了。3.4 系统规模
统计规则：每行80字节，10%空行率。3.4.1 简化前jsp+java文件，共05083 bytes。Java文件，共4197776 bytes。约4.5万行代码；497张表24个视图。3.4.2 简化后jsp+java文件，共3104918 bytes。Java文件，共4197776 bytes。约2.8772万行代码；107张表8个视图。4 客户程序编写者需要了解的类和接口
如果有一个完整的基于OFBIZ2.0的开发过程定义和OFBIZ资深顾问做基础，一个开发团队中的开发者只需要了解以下类所提供的接口即可在OFBIZ2.0框架的基础上，开发基于实体引擎和服务引擎的应用程序。4.1 实体引擎核心应用类（客户端API）
涉 及到12个类，GenericDelegator，GenericValue，GenericPK，EntityCondition， EntityExpr，EntityFieldMap，EntityConditionList，EntityWhereString， EntityOperator，EntityOperator，EntityListIterator，这些类都是为GenericDelegator的
接口服务的。用户端程序和数据库之间的所有交往多是通过“GenericDelegator”完成的。4.2 服务引擎应用类（服务器端API）
涉及LocalDispatcher， GenericDispatcher； ServiceDispatcher；ServiceUtil；DispatchContext ；ServiceConfigUtil等6个类。4.3 常用工具类
工具类主要在包org.ofbiz.core.util中。1、 属性文件访问工具类：UtilProperties。2、 Map、List对象操作工具类：UtilMisc。3、 UtilFormatOut ：通用格式化输出工具类（主要用在 Jsp文件或View Helper中）。4、 UtilURL：得到文件流的URL地址类。5、 UtilCache：缓存管理类。6、 UtilValidate：通用数据输入输出数据校验（合法性和有效性）类，可任意扩展。.7、 UtilDateTime：java.util.Date和java.sql.Date格式的日期/时间处理类。8、 StringUtil：增强的字符串处理类。9、 UtilXML：增强的符合JAXP & DOM 规范的XMl解析器处理工具类。10、 SiteDefs：常数定义类，定义所有Web 程序用到的和环境有关的常量。11、 Debug：格式化输出程序调试信息类。12、 HttpClient：模拟一个HttpServlet请求类。13、 HttpRequestFileUpload：接受一个通过Http上传的文件工具类。14、 SendMailSMTP：符合SMTP协议的邮件发送处理类（实现发送邮件服务器的功能）。4.4 其它
作为一个初级的开发者来说，用好上述这些类加上基于OFBIZ的开发过程定义就可以了；但对于一个真正要用好OFBIZ的开发者，远不止上面这些，需要全面理解和掌握OFBIZ的流程、框架和代码。
原文地址：https://blog.csdn.net/honglei_zh/article/details/30120329
