<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

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

    Feedback

    # re: [導(dǎo)入]再談普元EOS中的數(shù)據(jù)總線  回復(fù)  更多評論   

    2007-04-24 15:57 by 方順
    一句話,eos對于業(yè)務(wù)的侵入性太強了!

    # re: [導(dǎo)入]再談普元EOS中的數(shù)據(jù)總線  回復(fù)  更多評論   

    2007-10-08 17:31 by 看熱鬧的人
    eos的思想值得借鑒,但是我個人感覺普元在將這種思想轉(zhuǎn)化成商業(yè)產(chǎn)品這步上不理想,也許這種思想根本就不適合以通用框架的形式推出。如果不這樣又怎么能夠?qū)崿F(xiàn)商業(yè)化呢?!
    主站蜘蛛池模板: 亚洲av永久无码精品秋霞电影秋| 亚洲午夜福利717| 久久精品国产亚洲AV久| 亚洲高清视频免费| 亚洲精品人成电影网| 18禁止看的免费污网站| 亚洲美女人黄网成人女| 波多野结衣在线免费观看| 亚洲三级视频在线| 成人黄18免费视频| 亚洲成AV人片在WWW| 又黄又爽的视频免费看| 一级特黄特色的免费大片视频| 男人的天堂亚洲一区二区三区| 无限动漫网在线观看免费| 亚洲国产成人99精品激情在线| 91在线视频免费91| 校园亚洲春色另类小说合集| 无码专区一va亚洲v专区在线| sss日本免费完整版在线观看| 亚洲AV综合色区无码一区爱AV| 亚洲AV无码片一区二区三区| 日韩精品成人亚洲专区| a级毛片在线视频免费观看| 久久狠狠高潮亚洲精品| 最近最好的中文字幕2019免费 | 青青草原亚洲视频| 久久精品免费一区二区三区| 亚洲成人高清在线观看| 国产精品免费大片| 精品国产成人亚洲午夜福利| 亚洲精品456播放| 18未年禁止免费观看| 亚洲av无码专区首页| 国产亚洲av片在线观看16女人| 永久在线观看www免费视频| 色天使亚洲综合一区二区| 亚洲精品国精品久久99热一| 野花高清在线观看免费完整版中文 | 久久久精品免费国产四虎| 亚洲不卡在线观看|