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 ——>GenericHelperDAO
GenericHelperDAO ——>GenericDAO
GenericDAO ——> SQLProcessor
SQLProcessor ——> 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的流程、框架和代碼。

總結

以上是生活随笔為你收集整理的使用OFBIZ的理由和不使用OFBIZ的理由的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。