許多人在開發分布式應用系統時會把許多的程序代碼和功能都編寫在應用程序服務器之中。因此許多應用

程序服務器的接口中便包含了數十，數百，甚至數千個方法和屬性讓客戶端應用程序使用。比較好一點的

程序員地知道在應用程序服務器中定義不同的接口，然后把方法和屬性歸類在適當的接口之中讓客戶端應

用程序使用。但是不管是使用單一接口或是多個接口，這種方法都造成了一個肥大的應用程序服務器，而

且這些方法和屬性不是無法重復使用，就是必須付出巨大的代價才能夠重復使用。事實上這種設計方法是

不正確的，在應用程序服務器應該使用許多不同的企業對象來共同完成工作，而不是使用一個巨大的對象

做完所有的事情。

分布式應用系統中客戶端應用程序不應該像傳統的二層結構應用程序一樣把所有的工作都編寫在客戶端的

應用程序之中，而是應該調用中介企業對象提供的服務來完成它需要進行的工作。

應用程序服務器則需要負責許多的工作，從后端數據庫中根據客戶端的需要來存取數據，執行企業法則，

以及提供客戶端需要的服務。

由于應用程序服務器需要進行這么多的工作，所以程序員在設計應用程序服務器時也絕不是把所有的程序

代碼寫在一起，而是應該經過分析和設計的階段把這些工作分配在不同功能的對象之中，并且讓這些對象

互相的合作來完成客戶端的需求。這些對象包括了專門負責存取數據的數據對象，代表實際世界中事物的

對象，例如客戶，訂單等的實體對象，負責執行企業功能的企業法則對象，提供特別計算或是服務的功能

對象，能及為了讓系統平順動作的控制對象或是協調對象等。在分布式計算環境中這些不同功能的對象都

統稱為企業對象。

可以重復使用的企業對象正是面向對象的好處，也是程序員在開發分布式應用系統時應用使用分析/設計/

實現的軟件工程方法。

功能對象
程序員可以把以往所謂的公用程序和函數歸化為數個功能對象，讓其它的程序代碼或是企業對象調用，而

不需要讓程序員使用COPY AND PASTE的方式讓這些程序代碼重復的出現在程序代碼中。使用功能對象不但

可以在這些功能改變時只需要修改功能對象即可，也可以減少其它應用程序或是企業對象的程序代碼大小

數據對象
負責存取數據的工作，最靠近數據庫的企業對象，遠程數據模塊便屬于數據對象的范疇。實體對象都是靠

數據對象取得它們的屬性，是最常在一起工作的企業對象。

無狀態對象
若中介軟件不使用無狀態對象，那么每一個客戶端應用程序都可能需要使用數個企業對象，而且這些企業

對象在客戶端應用程序沒有結束執行時都無法釋放。那么中介軟件在服務了一定數量的客戶端應用程序之

后就再也無法服務其它的客戶端應用程序。無狀態對象的屬性在使用之后能夠立刻的釋放給其它的用戶使

用，所以在分布式應用系統中客戶端應用程序使用的企業對象都是無狀態對象，那么中介軟件或是應用程

序服務器就可以同時服務的客戶端應用程序數目便可以大幅的增加，進而增加分布式應用系統的延展性。

雖然企業對象的觀念很簡單，但是如何開發良好的企業對象卻不是那么簡單，這需要經理以及對于使用的

軟件技術有深入的了解。如何設計適當的企業對象是非常重要的，如何有效率的讓企業對象和客戶端應用

程序通訊更是一門需要實務經驗的學問。因為不管理論怎么說，程序員最終是需要把分布式應用系統實現

出來的，光有口頭上的理論而沒有實際的實現技術對于程序員來說是沒有用的。

許多程序員幾乎把所有程序代碼都編寫在遠程數據模塊之中。這會讓遠程數據模塊成為一個large 

grained企業對象，這種結構不但不易維護，其執行效率和延展性都有問題。
就執行效率來說，許多程序員在應用程序服務器（遠程數據模塊）之中定義了許多輸出的方法和屬性，然

后讓客戶端應用程序大量的使用這些方法和屬性。但是請各位記得當我們在分布式應用系統中調用遠程的

方法時，這比起一般的程序和函數的調用來說是非常緩慢的，而且這種結構讓編寫客戶端程序的程序員了

解了太多中介企業對象的結構，進而降低了企業對象和應用程序服務器的透明性。在是后維護企業對象和

應用程序服務器都會造成負擔。

客戶端應用程序只需要和應用程序服務器之中特定的協調對象通訊，并且要求協調對象或是控制對象來完

成客戶端應用程序需要進行的工作即可，客戶端應用程序不需要知道協調對象會使用那些企業對象來共同

完成工作。這樣不但有比較好的執行效率，更增加了應用程序服務器的透明性。

上面的討論的并不是絕對正確的，程序員還是需要根據應用系統的需求來設計系統結構。但是一般來說上

面的討論的觀念和結構是程序員在設計分布式應用系統時應該有的觀念和使用的設計方式。