判斷和循環是程序中最基本的語句結構。而在vonNeumann體系架構下，循環是對集合進行操作所需的基本步驟。一個有趣的事實是，函數式語言所宣稱的 生產力的來源很大程度上在於集合操作的便捷性。在數學中我們通過張量分析，泛函分析等可以清楚地意識到集合之間的相互作用是可抽象的，是可以獨立理解的， 即我們可以在不涉及具體基元結構的層面上獨立的定義並執行集合運算。如何將這種概念獨立性在框架層面展開是一個非常深刻的命題。
在基元結構上應用基礎操作p(d)這一微觀場景一般情況下是容易理解並實現的, 但通常程序中所定義的大量邊界是基於集合變量的, 因此很多代碼都是封包和解包操作, 在層層嵌套的循環結構深處我們才能發現真正具有業務價值的基元結構. 將集合操作提升到系統層，減少或簡化在應用層需要顯式編制的循環結構是框架設計層面需要考慮的問題.
一個最基本的方法是儘量定義通用的同構操作, 避免構造中間集合. 例如前後臺之間通過json等通用協議交換複雜結構的對象, 避免定義特殊的中間處理過程. 一個與之相配合的重要技術手段是通過類查詢語句(描述方式)直接構造特定的集合. 例如prototype.js中提供的$$('div div.myclass').each(op)這樣的處理方式顯然要比在循環過程中基於特定條件過濾要方便的多. 而在AOP操作中切點的集合定義方式也是其提供的核心價值之一. 與集合操作相適應的一種代碼風格是流式設計(stream), 這正是jQuery試圖鼓吹的主要價值(雖然我個人認爲它有些走極端). 流式設計的核心結構實際上是 x += dx, 它不需要集合是一次性構造的, 便於支持一種逐步部分修正的概念模型.
爲了支持集合的隱式構造, 我們需要以通用的方式定義元素到集合的組裝規則. 在Witrix平臺的前臺js框架中我們定義了由獨立的html組件到複合查詢條件的拼接規則, 定義了由每個html組件的數據校驗函數到整個form的數據校驗函數之間的組裝規則, 定義了由單個html組件提交參數到整個form提交參數之間的組裝規則. 在Witrix平臺的標準界面上, 框架本身的編制基於js.query.buildCondition(frmQuery), js.validate.validateForm(frmUpdate), ajax.addForm(frmUpdate)等少量集合操作進行, 在不同的應用場景下, 我們只需要關心每一個字段如何顯示, 提交哪些屬性, 而由系統負責將它們自動組裝並在後臺進行分派. 面向不同的應用, 框架代碼不需要做出任何修改, 確保了系統結構的可重用性.
Witrix平臺的後臺處理模型中定義了實體化過程, DaoWebAction基於CRUD等原子操作定義了批量提交, 數據導入導出等複合的甚至是嵌套的集合操作. 在不同的應用中, 我們通過修改bizflow文件中<action id="ViewDetail-default">, <action id="Update-default">等針對單實體的業務規則即可適應不同的業務場景, 而不需要爲特定的應用重複編制集合處理過程.
面向集合+通用組裝規則是Witrix平臺設計中採用的基本設計手法之一, 它使得我們在一般應用中只需要考慮單實體,單字段等基元結構上發生的特定業務, 大大簡化了系統構造過程. 但是也需要認識到從個體到集合的擴張(p(d) -> P(D) )是非平凡的, 集合比個體的簡單加和要更多, 爲此架構中需要保留對集合邊界的識別能力, 例如需要允許在數據導入完成之後執行特定的業務規則而不是僅僅針對每一數據行執行業務規則.
在基元結構上應用基礎操作p(d)這一微觀場景一般情況下是容易理解並實現的, 但通常程序中所定義的大量邊界是基於集合變量的, 因此很多代碼都是封包和解包操作, 在層層嵌套的循環結構深處我們才能發現真正具有業務價值的基元結構. 將集合操作提升到系統層，減少或簡化在應用層需要顯式編制的循環結構是框架設計層面需要考慮的問題.
一個最基本的方法是儘量定義通用的同構操作, 避免構造中間集合. 例如前後臺之間通過json等通用協議交換複雜結構的對象, 避免定義特殊的中間處理過程. 一個與之相配合的重要技術手段是通過類查詢語句(描述方式)直接構造特定的集合. 例如prototype.js中提供的$$('div div.myclass').each(op)這樣的處理方式顯然要比在循環過程中基於特定條件過濾要方便的多. 而在AOP操作中切點的集合定義方式也是其提供的核心價值之一. 與集合操作相適應的一種代碼風格是流式設計(stream), 這正是jQuery試圖鼓吹的主要價值(雖然我個人認爲它有些走極端). 流式設計的核心結構實際上是 x += dx, 它不需要集合是一次性構造的, 便於支持一種逐步部分修正的概念模型.
爲了支持集合的隱式構造, 我們需要以通用的方式定義元素到集合的組裝規則. 在Witrix平臺的前臺js框架中我們定義了由獨立的html組件到複合查詢條件的拼接規則, 定義了由每個html組件的數據校驗函數到整個form的數據校驗函數之間的組裝規則, 定義了由單個html組件提交參數到整個form提交參數之間的組裝規則. 在Witrix平臺的標準界面上, 框架本身的編制基於js.query.buildCondition(frmQuery), js.validate.validateForm(frmUpdate), ajax.addForm(frmUpdate)等少量集合操作進行, 在不同的應用場景下, 我們只需要關心每一個字段如何顯示, 提交哪些屬性, 而由系統負責將它們自動組裝並在後臺進行分派. 面向不同的應用, 框架代碼不需要做出任何修改, 確保了系統結構的可重用性.
Witrix平臺的後臺處理模型中定義了實體化過程, DaoWebAction基於CRUD等原子操作定義了批量提交, 數據導入導出等複合的甚至是嵌套的集合操作. 在不同的應用中, 我們通過修改bizflow文件中<action id="ViewDetail-default">, <action id="Update-default">等針對單實體的業務規則即可適應不同的業務場景, 而不需要爲特定的應用重複編制集合處理過程.
面向集合+通用組裝規則是Witrix平臺設計中採用的基本設計手法之一, 它使得我們在一般應用中只需要考慮單實體,單字段等基元結構上發生的特定業務, 大大簡化了系統構造過程. 但是也需要認識到從個體到集合的擴張(p(d) -> P(D) )是非平凡的, 集合比個體的簡單加和要更多, 爲此架構中需要保留對集合邊界的識別能力, 例如需要允許在數據導入完成之後執行特定的業務規則而不是僅僅針對每一數據行執行業務規則.
