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

?
?

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

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

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

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

我一直使用第三種
?
?

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

關(guān)于SOA, 推薦一個網(wǎng)站 www.soacentral.com, 這是BEA, 微軟發(fā)起的一個consortium. 上面有SOA藍(lán)圖和BEA, J2EE 和微軟的參考實(shí)現(xiàn).

SOA和OO不是一個層面的東西. OO的適用范圍是偏向系統(tǒng)底層的, 比如編程, 構(gòu)件設(shè)計(jì). SOA是偏向宏觀的, 比如集成, 整合, 工作流.

SOA的一個成型的例子是WSRP. 這里的SERVICE是一個PORTLET, 而服務(wù)客戶是PORTAL. 與傳統(tǒng)PORTAL不同的是這個PORTLET不是本地的, 而是基于WEB SERVICES的, 并且可以通過ESB解偶. 當(dāng)然, WSRP有它的特殊性, 因?yàn)檎系牡攸c(diǎn)是在最終用戶面前, 呵呵.
?
?

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

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

?

對每個用例

建立一個用例實(shí)現(xiàn)

補(bǔ)充用例描述（如果需要的話）

從用例行為中，找出分析類
如果我們嚴(yán)格按照RUP過程進(jìn)行，下一步應(yīng)該是：

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

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

數(shù)據(jù)驅(qū)動的方法

行為驅(qū)動的方法，和

職責(zé)驅(qū)動的方法。

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

行為驅(qū)動的方法有著雙重的成立理由。首先找出類執(zhí)行的操作，從中決定這些操作涉及的數(shù)據(jù)中，哪些應(yīng)該被這個類所擁有。這很棒，但是我們?nèi)绾未_認(rèn)我們?yōu)轭愓页龅牟僮髦g能夠保持一致呢？如何區(qū)分操作和類，以明確這個操作是屬于這個類，但是 其它的操作要屬于同一個類，還是其它的類？我們需要某種方法來區(qū)分各個操作。這就是職責(zé)驅(qū)動的方法帶給我們的。

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

一旦我們確定了我們的類的職責(zé)，我們就可以設(shè)計(jì)一個分析類圖，來描述類間關(guān)系的整體結(jié)構(gòu)。這個結(jié)構(gòu)一般都是由業(yè)務(wù)領(lǐng)域決定的。一個UML分析類圖可以幫助我們可視化的把這個關(guān)系的結(jié)構(gòu)表示出來。

因此，我建議對標(biāo)準(zhǔn)的RUP過程做如下修改（次序的改變）：粗體）：

對每個分析類

描述類的職責(zé)

在分析類圖上，建立分析類間的聯(lián)系

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

描述每個類的屬性和關(guān)系

定義類的屬性

描述分析類間事件的相關(guān)性
u][b][/b][b][/b]
?
?

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

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

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

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

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

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

于是產(chǎn)生了SPRING, 于是產(chǎn)生了HIBERNATE. 在TomCat + Struts + Spring + hibernate的領(lǐng)域里, "Business Tier" 成為一個純粹的設(shè)計(jì)概念, 不再具備"物理部署"層面的含義.

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

說這么多廢話的意思, 是有時我們?nèi)菀淄? 分離"狀態(tài)"和"方法"的"模式", 是為了一個理由而存在的. 在回答"BO"該不該具備"方法"或者"狀態(tài)"的時候, 我們似乎更應(yīng)該關(guān)心下面的這些問題:

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

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

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

2. 從降低偶合角度看, 復(fù)雜數(shù)據(jù)結(jié)構(gòu)而不具備相應(yīng)邏輯方法的對象是難以使用的. 可以想象, "業(yè)務(wù)邏輯對象"的客戶程序?qū)⑿枰獜?fù)雜的代碼來維護(hù)這個BO的數(shù)據(jù)完整性. 這樣的設(shè)計(jì)極大地增加了客戶程序和業(yè)務(wù)邏輯對象之間的偶合度.
相反, 如果BO和業(yè)務(wù)邏輯對象合而為一, 那么BO本身可以負(fù)責(zé)自身屬性數(shù)據(jù)的檢驗(yàn). 比如, 可以用有限狀態(tài)模式來設(shè)計(jì)BO, 既增加BO界面的一致性, 也降低客戶程序的復(fù)雜度.

EJB3, AJAX, XAML, XUL, 還有其他平臺和客戶端技術(shù)的出現(xiàn), 應(yīng)該讓我們不斷質(zhì)疑和反思現(xiàn)在"傳統(tǒng)"和"模式". 跟隨"模式"是不可能有創(chuàng)新的.

?
?

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

delete,list的操作應(yīng)該屬于DbObjectManager
insert,load,update以及其他業(yè)務(wù)邏輯應(yīng)該屬于Word程序即BO

?
?