?? 前兩天一位普元的朋友衣風(fēng)
http://blog.sina.com.cn/u/1495516693在我的blog上留言,談到對(duì)數(shù)據(jù)總線的不同看法. 我本人并未使用過(guò)普元EOS,所做的判斷只是基于我個(gè)人膚淺的第一印象, 很有可能是不準(zhǔn)確的. 不過(guò), 目前我仍然堅(jiān)持自己對(duì)于普元EOS的看法,呵呵.
?? ?
??? 1. EOS產(chǎn)生的xml描述文件中的大量條目都是EOS自身的結(jié)構(gòu)要求，而與實(shí)際業(yè)務(wù)無(wú)關(guān)，即EOS描述文件中的有效信息量密度很低.
??? 衣風(fēng)認(rèn)為條目并不是EOS自身的結(jié)構(gòu)要求，而是業(yè)務(wù)對(duì)象的結(jié)構(gòu)描述.
這里我的看法是業(yè)務(wù)對(duì)象應(yīng)該盡量通過(guò)領(lǐng)域(Domain)語(yǔ)言來(lái)描述, 領(lǐng)域信息的外在表象應(yīng)該盡量是卷縮的,而不是展開(kāi)的,
應(yīng)該盡量是抽象的而不是實(shí)現(xiàn)細(xì)節(jié)層面上的.例如:
??? <function class="test.MyFunctionProvider">
??????? <args>
??????????? <arg>
??????????????? <name>argA</name>
??????????????? <value>3</value>
??????????? </arg>
??????? </args>
??? </function>
??? 以上信息可以描述一個(gè)方法調(diào)用, 這里的function, args, arg, name,
value等標(biāo)簽的設(shè)置都是解析器為了理解該調(diào)用的語(yǔ)義而規(guī)定的結(jié)構(gòu)元素,這些元素并不屬于函數(shù)本身.
例如我們可以規(guī)定如下的調(diào)用格式來(lái)簡(jiǎn)化描述文件而不損失信息,
??? <function class="test.MyFunctionProvider">
??????? <arg name="argA">3</arg>
??? </function>
??? 而在我們的工作流引擎中, 業(yè)務(wù)操作的調(diào)用以封裝后的形式出現(xiàn)
??? <BusinessA:DoWorkA argA="3"/>
??? 通過(guò)標(biāo)簽封裝之后, 我們?cè)谡{(diào)用的時(shí)候所需要提供的信息是最小化的, 每一個(gè)涉及到的元素都是有著業(yè)務(wù)含義的,
而將解析器本身的結(jié)構(gòu)要求隱蔽在封裝的標(biāo)簽定義中.此后我們?nèi)绻鼡Q了實(shí)現(xiàn),而業(yè)務(wù)需求不變, 則我們的調(diào)用處是不會(huì)受到影響的.
??? 現(xiàn)在基于xml語(yǔ)法的文件格式很多, 我們的工作流引擎也采用了xml描述. 但是我們的一個(gè)基本觀點(diǎn)是,
xml配置文件解析器不應(yīng)該直接理解文件中所有的標(biāo)簽, 即它只需要理解自身的結(jié)構(gòu)元素, 而為引入Domain知識(shí)保留余地.
???
??? 2. 普元EOS中的結(jié)構(gòu)似乎很難進(jìn)行有效的擴(kuò)展。而所謂的xml總線技術(shù)更加劇了這一點(diǎn)
???
衣風(fēng)認(rèn)為"正是將XML作為數(shù)據(jù)傳遞的總線，才使應(yīng)用在數(shù)據(jù)層次上具有了較強(qiáng)的擴(kuò)展能力"。從面向?qū)ο蟮挠^點(diǎn)看,
程序中普適性的基本基元是數(shù)據(jù)與行為的集合體, 而程序模塊之間的交互也絕不僅僅是通過(guò)數(shù)據(jù)來(lái)進(jìn)行, 而是往往呈現(xiàn)出一種數(shù)據(jù)與行為的交織狀況.
普元的模型應(yīng)該包含了大量發(fā)生緊密關(guān)聯(lián)的局部元素, 它們應(yīng)該處在同一進(jìn)程(狀態(tài))空間中, 直接訪問(wèn)對(duì)象應(yīng)該是最簡(jiǎn)單,最經(jīng)濟(jì),
最完備的信息傳遞方式,
而"xml節(jié)點(diǎn)的表達(dá)能力遠(yuǎn)遠(yuǎn)超越了普通的數(shù)據(jù)類(lèi)型，但充其量也不過(guò)是對(duì)現(xiàn)有數(shù)據(jù)的規(guī)整的樹(shù)形表示，并不具有動(dòng)態(tài)計(jì)算能力（甚至是最簡(jiǎn)單的lazy
evaluation）". 實(shí)際上對(duì)于所謂的總線, 最簡(jiǎn)單的模型是一個(gè)可以動(dòng)態(tài)管理的變量集合, 那么一個(gè)Map就足夠了.
在集合中我們可以保存各種對(duì)象, 比如xml節(jié)點(diǎn), 但是又不限于xml節(jié)點(diǎn). 從建模的角度上說(shuō),
把xml節(jié)點(diǎn)定義為一級(jí)集合元素我認(rèn)為是不合適的. 通過(guò)對(duì)象的成員函數(shù), 我們?cè)趯?duì)象圖中可以包含大量的動(dòng)態(tài)計(jì)算信息, 例如
???? obj.getSomeCalculatedAttribute().getLazyLoadValue()
??? 這些動(dòng)態(tài)語(yǔ)義在純數(shù)據(jù)含義的xml總線技術(shù)中不知道如何表達(dá).
??? 對(duì)象圖表達(dá)數(shù)據(jù)關(guān)聯(lián)的能力也強(qiáng)于樹(shù)形結(jié)構(gòu)的xml節(jié)點(diǎn), 例如 obj.getRefObj().getRefObj() == obj, 不知道這樣的關(guān)聯(lián)在普元EOS的數(shù)據(jù)總線中如何表達(dá).
??? 在并發(fā)訪問(wèn)中如果需要同步, 對(duì)于對(duì)象, 我們可以使用synchronized機(jī)制, 但是對(duì)于xml節(jié)點(diǎn)不知道如何才能有通用的處理方式.?