我們在開發系統時,一般VO（或者是PO）對應的是數據庫中的表中的記錄，view object是提供給客戶端顯示用的對象，在業務邏輯部分是BO。在很多情況下，我們把VO或者是PO作為了BO，但是在復雜的業務環境中，這種方式的脆弱性就體現出來了，如果我的業務對象比較復雜（具體來說，比如包含了多個表，多個視圖中的數據），就沒辦法將VO、PO作為BO用了。這時候我們需要專門做一層業務層，通過拼裝軟干個PO、vo來構造我們需要的BO，以及按一定的業務邏輯處理這些BO，并生成相應的view object提供給客戶端。我的疑問是：
1、這方面有沒有成熟的架構或者案例？
2、關于BO的構成：
2.1、BO中是否應該既包含業務對象的屬性又應該包含業務方法？
2.2、或者是BO只包含業務對象的屬性，對BO的所有操作都由業務邏輯對象處理？
2.3、或者BO中包含業務對象的屬性以及Retrieve，Update，Create，Delete等操作，而業務邏輯由專門的業務邏輯對象處理？
?Re: 關于BO的問題? 發表時間: Jul 17, 2005 7:55 AM?? 回復?
?
發表人: banq??? 發表文章: 5226 / 來　　自: 上海 / 注冊時間: 2002-08?
你的疑問正好和這篇文章討論的一致：

BO中是否應該既包含業務對象的屬性又應該包含業務方法？
在Ruby on Rails/Naked Objects精神指引下的域驅動開發框架

>1、這方面有沒有成熟的架構或者案例？
你這是SOA架構，是業務層加Domain，現在大量的J2EE都是這種架構

》2、關于BO的構成：
》2.1、BO中是否應該既包含業務對象的屬性又應該包含業務方法？
現在SOA架構是不包括業務方法，被稱為貧血模型;Naked Object是兩者都包括，但這是一個研究方向。
>2.2、或者是BO只包含業務對象的屬性，對BO的所有操作都由業務邏輯對象處理？
是的
>2.3、或者BO中包含業務對象的屬性以及Retrieve，Update，Create，Delete等操作，而業務邏輯由專門的業務邏輯對象處理？
一般BO只包括屬性，CRUD也屬于業務操作了，我認為屬性和業務方法分離屬于橋模式，分離是為了更靈活的組裝，SOA也不違反OO，不過因為OO的"教皇"Martin fowler一句來自感覺的話：感覺不美，貧血模型；我相信不出，在一個分布環境中和一個互聯共享環境中，如果把BO拿出來共享，而不是Service，會產生什么樣后果。也許“教皇”不是凡人，比你我看得很遠，可惜我是倡導“上帝死了”的人。

?
?

?Re: 關于BO的問題? 發表時間: Jul 18, 2005 12:46 PM?? 回復?
?
發表人: redlly??? 發表文章: 42 / 注冊時間: 2003-07?
SOA好象是基于服務的架構,能說說和這個具體有什么關系嗎?
?
?

?Re: 關于BO的問題? 發表時間: Jul 23, 2005 11:01 AM?? 回復?
?
發表人: flyinair2000??? 發表文章: 10 / 注冊時間: 2004-08?
Martin fowler一句來自感覺的話：感覺不美，貧血模型
－－－－－－－－－－－－－－－
這根本不是感覺的話，這樣的模型又回到了procedural programming的老路上了。
procedural progrmming 告訴我們“世界就是世界，你就是你”。
oo說“世界就是你，你就是世界”。
現在多了一個SOA這個BUZZWORD，說的卻還是“世界就是世界，你就是你”。除了在哲學理論上我可以看出它的“螺旋式上升”的進步以外，其他看不出有什么意義。（以上的“世界”和“你”　差可比擬為“method"和“property")

另外，什么是soa? 誰也搞不清楚。（看最近TSS.NET上的一篇，MS　（PDC?) 2005 大會上誰都講SOA,誰都說不清。但是已經有architect宣稱SOA是類似于oo　的paradigm shift了，搞笑不搞笑？）
近來如果可以算作paradigm的話，個人認為恐怕要數AOP為代表的方面編程了。
?
?

?Re: 關于BO的問題? 發表時間: Sep 9, 2005 8:30 AM?? 回復?
?
發表人: Kyle_Yin??? 發表文章: 26 / 注冊時間: 2005-09?
"這根本不是感覺的話，這樣的模型又回到了procedural programming的老路上了。"

除了OOP還是PROCEDURAL的編程風格之外, 其實這里有令一個重要因素大家沒有提及: 性能.

很多大系統, 至少我聽說過(看過DIAGRAM)的和親眼見過(CODE)的系統(呵呵, 其實也沒幾個), 大多是盡可能采用無狀態設計. 無狀態的組件界面看上去當然象PROCEDURAL函數. 這樣做的原因, 主要是為了性能. 在分布計算環境里, "狀態"往往意味著"地點親合", "地點親合"往往意味著"性能瓶頸".

我發現直白英文翻譯成中文馬上就發酸了.

?
?

?Re: 關于BO的問題? 發表時間: Jul 23, 2005 11:07 AM?? 回復?
?
發表人: flyinair2000??? 發表文章: 10 / 注冊時間: 2004-08?
或者是BO只包含業務對象的屬性，對BO的所有操作都由業務邏輯對象處理？
------------
至少我見過的所有經典j2ee書中都是講要包含邏輯處理的。
service只是一層wrapper而已，不包含太多的邏輯。
?
?

?Re: 關于BO的問題? 發表時間: Jul 24, 2005 12:13 PM?? 回復?
?
發表人: redlly??? 發表文章: 42 / 注冊時間: 2003-07?
> 至少我見過的所有經典j2ee書中都是講要包含邏輯處理的。
> service只是一層wrapper而已，不包含太多的邏輯。

我們知道，在特定的領域中，如果不發生革命性的變化，一般來說這個領域的核心數據基本是穩定的。也就是說我們可以抽象出特定領域的穩定數據模型；而在領域中的業務邏輯的變動是比較大的，是難以被固化的。最典型的案例莫過于移動、連通的資費吧，今天一個優惠，明天一個酬賓，業務邏輯可謂是變化五窮，但是它們的基本數據基本還是保持不變，如：資費、時長等等。
這樣來說如果在BO中即包含業務對象的屬性又包含業務邏輯，在業務需要變動的時候將不可避免的對BO進行修改，更可怕的是，在業務邏輯比較煩多復雜的時候出現包括數十數百個方法，數千上萬行代碼的巨無霸BO的出現。這跟對象間解耦、分離的理念是嚴重背離的。

?
?

?Re: 關于BO的問題? 發表時間: Jul 24, 2005 12:21 PM?? 回復?
?
發表人: redlly??? 發表文章: 42 / 注冊時間: 2003-07?
對于SOA（基于服務的架構），我也查過不少資料，包括M$、IBM、BEA等等。但是給我的感覺是SOA只是一種理念，好像并沒有一個統一的標準，或者說沒有一個可以拿來做實例的案例架構，不像OO、DAO等設計模式。大多數廠商的對SOA的解釋也不同、解決方案更是像在做廣告，讓人越看越迷糊。誰能詳細的闡述一下SOA，或者用幾句話概括一下SOA。
?
?

?Re: 關于BO的問題? 發表時間: Jul 24, 2005 12:42 PM?? 回復?
?
發表人: banq??? 發表文章: 5226 / 來　　自: 上海 / 注冊時間: 2002-08?
SOA有兩者含義：一種是你說的SUN等公司提出那種理念，這更多是一種商業概念；還有一種是J2EE的開發模式的概念，見老外這篇文章可能符合我們這個話題的討論：
http://dotavery.com/blog/archive/2004/01/04/215.aspx
在這個話題中，SOA就是將Model中的業務邏輯分離出來，單獨形成一個服務，我們編程時就是面向這些服務編程了，當然原理的模型因為被抽取主要行為，變成了貧血模型了；但是我認為這符合GOF的橋模式。所以SOA并不是一種反設計的架構。

?
?

?Re: 關于BO的問題? 發表時間: Jul 26, 2005 2:34 PM?? 回復?
?
發表人: flyinair2000??? 發表文章: 10 / 注冊時間: 2004-08?
有很多時候，并不是不能用OO解決問題，而是我們沒有能力應用OO而已。
至少，對于你講的資費問題，并不是沒有OO的解決辦法。
加上一個service layer，并沒有自動解決系統解耦問題，（相反增加了耦合程度。為什么？我也不想說了。－－知道的自然知道，不知道的爭論半天，也不會有什么結果。國內論壇，抬杠罵架的居多，不想多說）
只是給一個原始的procedural　programming 加上一個漂亮的wrapper而已。

總之，各人仁者見仁，智者見智吧。
?
?

?Re: 關于BO的問題? 發表時間: Jul 29, 2005 11:08 AM?? 回復?
?
發表人: redlly??? 發表文章: 42 / 注冊時間: 2003-07?
看了不少資料，關于BO（bussiness object）有不少種概念，主要有如下三種：
1、只包含業務對象的屬性；
2、只包含業務方法；
3、兩者都包含。
呵呵，看起來是仁者見仁了。bang的看法應該是第一種，如果是這樣我還是比較偏向于bang的看法。其實怎么定義并不重要，這些東西原本就已經在各種項目、各種模式中存在，只是叫法不同。重要的是要找到一種適合自己項目的模式。
?
?

?Re: 關于BO的問題? 發表時間: Aug 25, 2005 6:52 PM?? 回復?
?
發表人: billywxy??? 發表文章: 14 / 注冊時間: 2003-11?
看了不少資料，關于BO（bussiness object）有不少種概念，主要有如下三種：
1、只包含業務對象的屬性；
2、只包含業務方法；
3、兩者都包含。

我一直使用第三種
?
?

?Re: 關于BO的問題? 發表時間: Sep 9, 2005 8:02 AM?? 回復?
?
發表人: Kyle_Yin??? 發表文章: 26 / 注冊時間: 2005-09?
"加上一個service layer，并沒有自動解決系統解耦問題"-----所以會有ESB一類的東西, 呵呵.

關于SOA, 推薦一個網站 www.soacentral.com, 這是BEA, 微軟發起的一個consortium. 上面有SOA藍圖和BEA, J2EE 和微軟的參考實現.

SOA和OO不是一個層面的東西. OO的適用范圍是偏向系統底層的, 比如編程, 構件設計. SOA是偏向宏觀的, 比如集成, 整合, 工作流.

SOA的一個成型的例子是WSRP. 這里的SERVICE是一個PORTLET, 而服務客戶是PORTAL. 與傳統PORTAL不同的是這個PORTLET不是本地的, 而是基于WEB SERVICES的, 并且可以通過ESB解偶. 當然, WSRP有它的特殊性, 因為整合的地點是在最終用戶面前, 呵呵.
?
?

?Re: 關于BO的問題? 發表時間: Aug 15, 2005 11:14 AM?? 回復?
?
發表人: kylix_xp??? 發表文章: 1 / 注冊時間: 2005-08?

我覺得這不是個問題,bo沒有了操作方法,還叫面向對象?比如說銀行帳號Account對象,存款deposit(),取款withdraw()操作不屬于Account對象，難道還屬于別的對象？這不是很自然嗎？
見 RUP統一軟件過程
http://www-128.ibm.com/developerworks/cn/rational/rationaledge/content/mar05/5383/?ca=dwcn-newsletter-rational#N10098

?

對每個用例

建立一個用例實現

補充用例描述（如果需要的話）

從用例行為中，找出分析類
如果我們嚴格按照RUP過程進行，下一步應該是：

把行為分配給分析類
基于以下理由，這一次，我又會對RUP過程做一點小的改動：回顧一下我們的進展。我們剛剛找到了8個實體類，我們認為這些都是我們系統中的類。在我們做下一步之前，我們需要給這8個實體類增加一些內容，來確認他們是類。

有三種基本的方法來充實我們的分析類：

數據驅動的方法

行為驅動的方法，和

職責驅動的方法。

數據驅動的方法對于從事數據庫工作，或者從事過程語言編程的人員來說很常見。他們就是用數據和數據之間的關系來認識、描述世界的，因此會首先去尋找類中的數據－一般沒有什么標準的方法去尋找類的函數或功能。這看起來不錯，[b]但是數據只是工作的一半。實際上， 類的準確定義，包括了數據和對數據進行的操作。[/b]

行為驅動的方法有著雙重的成立理由。首先找出類執行的操作，從中決定這些操作涉及的數據中，哪些應該被這個類所擁有。這很棒，但是我們如何確認我們為類找出的操作之間能夠保持一致呢？如何區分操作和類，以明確這個操作是屬于這個類，但是 其它的操作要屬于同一個類，還是其它的類？我們需要某種方法來區分各個操作。這就是職責驅動的方法帶給我們的。

職責驅動的方法是自上而下的，從總體的類及其職責的視圖開始。首先定義一個類在業務中的“使命”，這個“使命”描述了這個類對外提供的服務。從軍事術語上來說，就是責任和策略。操作和數據是戰術層面上的（為戰略服務的，服從于某些目標、策略的）。 2

一旦我們確定了我們的類的職責，我們就可以設計一個分析類圖，來描述類間關系的整體結構。這個結構一般都是由業務領域決定的。一個UML分析類圖可以幫助我們可視化的把這個關系的結構表示出來。

因此，我建議對標準的RUP過程做如下修改（次序的改變）：粗體）：

對每個分析類

描述類的職責

在分析類圖上，建立分析類間的聯系

把行為指定給分析類（找出操作）

描述每個類的屬性和關系

定義類的屬性

描述分析類間事件的相關性
u][b][/b][b][/b]
?
?

?Re: 關于BO的問題? 發表時間: Aug 16, 2005 6:40 PM?? 回復?
?
發表人: 大愚弱智??? 發表文章: 7 / 注冊時間: 2004-09?
BO中包含業務對象的屬性以及等操作，而業務邏輯由專門的業務邏輯對象處理－－我除了覺得這樣做很合理外，甚至還建議把Retrieve，Update，Create，Delete等操作也放到專門的業務邏輯的bean來處理。

把BO當成一個參數傳給專門的業務邏輯的bean，把操作和屬性分開也見得違反了OO。
專門的業務邏輯的bean一般由容器管理它的狀態，這些bean可能還需要容器管理的事務，假如把屬性糅合進去也給容器管理好像就不是很適合了。
?
?

?Re: 關于BO的問題? 發表時間: Sep 9, 2005 10:24 AM?? 回復?
?
發表人: Kyle_Yin??? 發表文章: 26 / 注冊時間: 2005-09?
個人意見, 大家對待J2EE模式有的時候太教條了.
切莫忘記很多J2EE模式是在歷史背景和特定語境下產生的. 比如: EJB1.1沒有"local interface", 早期的容器又缺少對remote EJB界面的優化, 和早期EJB設計者對于客戶端多樣性的一些設想.

EJB的初衷是純粹的構建在RMI上的"地點透明". 這個美好的初衷的前提假設是多樣化的客戶端類型, 比如 HTML, 獨立Swing client, Applet client, Midlet client. EJB1 就建立在這個假設之上. 可是很快大家意識到:
1. 這樣做的代價是無區別無止境的marshalling, 從而導致性能惡化.
2. 絕大部分J2EE應用是WEB應用, 而WEB 容器和EJB容器通常在一個JVM之內. 沒有必要Marshalling.
3. Swing client, Applet, Midlet和其他客戶端可以通過其他途徑呼叫EJB, 比如WEB SERVICES, 而沒有必要用RMI. 事實上RMI-IIOP往往無法通過放火墻, 而SOAP-HTTP則沒有這個問題. 對于廣域分布應用, web services比RMI更適合做傳輸手段. 而WEB SERVICES又是可以部署在WEB容器上的, 和EJB同在一個JVM內.
4. 容器生產者往往采用一些優化措施省略不必要的marshalling. 比如在weblogic上, 即使使用了remote EJB, 如果這個ejb部署在本地(JVM), 那么呼叫操作是不通過Socket進行的, 事實上等同于后來的local interface.

在這些發現的指導下, 第一代"核心J2EE設計模式"的主要目的是抵消EJB1的缺點. 比如 Session Facade, Transfer Object的主要目的在于粗糙通信粒度, 減少 Socket 和 marshalling. 而EJB2標準進一步引入了"local interface". 容器生產商也推薦開發者使用這些模式. 自此, EJB 層 與 WEB 層的"共同部署"作為J2EE模式的核心, 成了天經地義.

問題是: 如果WEB LAYER和BUSINESS LAYER"共同部署"在一個JVM里, 那EJB除了"事物處理"和"容器管理永久化"之外, 還有什么意義?

于是產生了SPRING, 于是產生了HIBERNATE. 在TomCat + Struts + Spring + hibernate的領域里, "Business Tier" 成為一個純粹的設計概念, 不再具備"物理部署"層面的含義.

可是有些傳統J2EE的模式保留了下來. 在一個單JVM系統里: Session Facade 和 Transfer Object 已經不具備性能上的必要性, 而更多地是一個審美取向和習慣做法. 當然, Session Facade作為事物處理的起點(spring)的意義仍然存在.

說這么多廢話的意思, 是有時我們容易忘記, 分離"狀態"和"方法"的"模式", 是為了一個理由而存在的. 在回答"BO"該不該具備"方法"或者"狀態"的時候, 我們似乎更應該關心下面的這些問題:

1. 這個BO是代表"交易事物"的, 還是具有"實體身份"的?
2. 這個BO的界面具備什么語意? 有狀態? 無狀態?
3. 這個BO和下面的永久層什么界面? 如何綁定?
4. 這個BO的部署有什么物理約束?
5. 這個BO現在和未來的客戶端是什么, 在哪里?

個人看法, 對于多數中小型, 單層JVM (橫向可以集群, 但是縱向"共同部署"在一個JVM里), WEB表達層和EJB業務層"共同部署"的應用而言, 一個完全作為"業務交易中間數據屬性集合"而不具備"業務邏輯方法"的BO屬于殺雞的鈍牛刀. 原因如下:

1. 沒有必要剝離"狀態"和方法. "業務邏輯對象"的客戶在這個環境里肯定是同一個JVM里, 作為WEB代理的的"SessionFacade", 作為Service代理的ApplicationService, 或者其他復合BO. 在"共同部署"前提下, 它們與BO之間的通信是純JAVA方法調用. 從性能角度分析, 不必用"無狀態"的設計原則來優化通信粒度. 事實上, Core J2EE Pattern里BO的第一個戰略"composite entity strategy"也推薦使用 local entity bean 實現BO.

2. 從降低偶合角度看, 復雜數據結構而不具備相應邏輯方法的對象是難以使用的. 可以想象, "業務邏輯對象"的客戶程序將需要復雜的代碼來維護這個BO的數據完整性. 這樣的設計極大地增加了客戶程序和業務邏輯對象之間的偶合度.
相反, 如果BO和業務邏輯對象合而為一, 那么BO本身可以負責自身屬性數據的檢驗. 比如, 可以用有限狀態模式來設計BO, 既增加BO界面的一致性, 也降低客戶程序的復雜度.

EJB3, AJAX, XAML, XUL, 還有其他平臺和客戶端技術的出現, 應該讓我們不斷質疑和反思現在"傳統"和"模式". 跟隨"模式"是不可能有創新的.

?
?

?Re: 關于BO的問題? 發表時間: Oct 14, 2005 4:14 PM?? 回復?
?
發表人: windfromsky??? 發表文章: 2 / 注冊時間: 2005-10?
用文件系統來比方一下:
BusinessObject是程序比如Word程序, 包含業務邏輯
DbObject 是文件, 只包含屬性
DbObjectManager 是資源管理器, 管理DbObject

delete,list的操作應該屬于DbObjectManager
insert,load,update以及其他業務邏輯應該屬于Word程序即BO

?
?