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