02年03月28日 11:18 互聯(lián)網

OFBIZ拒絕這種混亂，一套EntityEngine機制輕松解決上述所有問題。
1、 涉及1張表（實體）的增、刪、改、查，它提供一套處理機制（不到12個類，大約5千行代碼），應用的規(guī)模是10000張表，它還是這套處理機制（不到12個類，大約5千行代碼），而且這些處理機制由JAVA程序高手生成和維護，可以保證其合理性、可靠性和安全性。
2、 EntityEngine提供了一個構造復雜sql操縱語句的機制，你可以根據需要隨時構造任意復雜的sql語句，完成你想要做的事情，這樣你可以在開發(fā)過程中，隨時修改你的數(shù)據庫定義，OFBIZ在系統(tǒng)啟動時會自動加載并檢測數(shù)據庫中的不一致性和參考完整性。
3、 實體引擎大大簡化了涉及關系型數(shù)據庫的管理和維護，但這還只是一小塊好處，大的好處是你在實現(xiàn)一個復雜需求的應用時，實體引擎用為數(shù)不多的幾個類解決了你所有的問題，實現(xiàn)任意復雜的數(shù)據庫存取業(yè)務和商業(yè)邏輯，而且與需求的復雜度和數(shù)量無關。
4、 好處太多了，在使用的過程中，會進一步的體會到。
1.5 錦上添花的服務引擎
服務框架（Services Framework）是OFBiz2.0 新增加的內容。服務（Services）被定義成一些相對獨立的邏輯處理單元（服務具有業(yè)務邏輯處理的原子性），能夠被靈活的組合成不同的形式去實現(xiàn)不同的商業(yè)邏輯需求。服務有多種類型的實現(xiàn)形式：工作流（Workflow）,（規(guī)則） Rules, Java程序（Java）, 簡單對象訪問控制協(xié)議（SOAP）, 輕量級Java程序腳本語言解釋器（BeanShell）等等。 如果一個服務被定義成"java"類型，意味著實現(xiàn)該服務的機制可能就是Java類的一個static方法, 而且，OFBIZ提供的服務框架不限于使用在一個基于Web的應用程序系統(tǒng)中。服務需要輸入一個Map形式的參數(shù)，服務處理完畢后，返回的也是一個Map形式的結果集。這個思路是非常好的，因為Map類型的數(shù)據格式很容易被序列化（serialized，序列化成字節(jié)流），并且通過HTTP(或SOAP)的協(xié)議進行存儲和傳輸。在OFBIZ里，服務被定義XML文件里，定義后的服務被分派給一個特定的 服務引擎（Service Engine） 。 服務引擎 具體負責以合適的方式進行服務的定義、管理和調用。 因為服務不一定被綁定在某基于Web的應用程序運行環(huán)境中，所以服務處理的結果也就不一定會和某erquest請求的響應reponse聯(lián)系在一起，這樣就允許服務可以在預先設置好的和時間點上定時觸發(fā)（因為它不需要一個Http Request請求），一般是通過系統(tǒng)提供的 工作日程管理器（Job Scheduler） 運行環(huán)境觸發(fā)（用定時器來控制對服務的調用）。
服務還可以互相調用調用，即一個服務被設置去調用任何其它的服務。這樣，我們可以用更小粒度的已經定義好的服務組合成一個服務鏈，來完成一個比較大的任務，而且這種組合是任意的，從已經定義好的服務本身來講，是很容易復用的。使用不同的應用程序系統(tǒng)中的服務，可以通過創(chuàng)建一個"全局服務定義文件"只被定義一次（因為服務本身是實現(xiàn)了特定的商業(yè)邏輯，它和具體應用的關系應該是松耦合的），當然，服務也可以通過一些限制，被指定為特定的應用程序所用。
在一個基于Web的應用系統(tǒng)中，服務可以被用來實現(xiàn)基于Web的事件（web events）,利用服務實現(xiàn)事件處理，可以在服務框架內最大可能的復用相對固定的一些業(yè)務邏輯。而且，服務還可以被定義成對可輸出的（exportable），意思是它們可以被系統(tǒng)外部的東西（可能是一個應用系統(tǒng)或其它）遠程訪問。 目前系統(tǒng)實現(xiàn)了一個基于簡單對象訪問控制協(xié)議（SOAP）的事件處理器，該事件處理器，就允許外部應用通過SOAP協(xié)議對運行（或定義）在其上的服務進行遠程訪問 。在將來，會有更多的遠程調用形式被加到服務框架里
1.6 雙管齊下
實體引擎和服務引擎各有利弊，在實際應用中，可以把服務引擎和實體引擎結合起來使用，實體引擎主要用于處理實體（Entities）對象的增、刪、改、查，服務引擎主要用于處理商務邏輯，這種商務邏輯的定義范圍，不大會遇到上面所說的要求一次查詢返回一個結果集這樣的服務定義（這完全可以用實體引擎來處理）。