|
|
地址(Address)是現(xiàn)代計(jì)算機(jī)體系架構(gòu)中的核心概念，它在程序設(shè)計(jì)語言上的體現(xiàn)就是C語言中的指針(Pointer)。在C語言中，所有的高級(jí)技巧都和指針這個(gè)概念相關(guān)。指針只是一個(gè)存放了一個(gè)地址的變量，但是C語言中提供了一個(gè)方便的間接訪問方式，p->x, 它使得擁有指針在概念上就等價(jià)于擁有了指針?biāo)傅娜績(jī)?nèi)容。在這種誘導(dǎo)下，我們漸漸模糊了地址和地址所存儲(chǔ)的內(nèi)容之間的區(qū)別。這也是指針的指針這樣的概念總是讓初學(xué)者迷惑不解的重要原因。
指針是對(duì)地址的符號(hào)化。它所帶來的第一大好處是使得我們擺脫了對(duì)絕對(duì)地址空間的依賴。如同Newton第一定律所闡述的：物理規(guī)律與所發(fā)生的慣性坐標(biāo)系無關(guān)。同樣，數(shù)字空間中發(fā)生的的事件與所處的絕對(duì)地址也是無關(guān)的。在符號(hào)化的方向上更進(jìn)一步，如果我們專注于指針的關(guān)聯(lián)語義，而放棄指針的指針這樣的混雜概念，就會(huì)得到具有獨(dú)立價(jià)值的引用(Reference)概念.
從表面上看起來，數(shù)字空間只是一個(gè)無限延展的一維地址空間，每一地址處只能存放一個(gè)有限大小的離散數(shù)值，似乎它的幾何學(xué)是貧瘠的。但是因?yàn)樵谲浖O(shè)計(jì)中，一般是不考慮尋址時(shí)間的。這意味著在擁有指針的情況下，我們可以“立刻”訪問到數(shù)字空間的任意遙遠(yuǎn)的地方。這種超時(shí)空的信息傳遞過程使得我們可以利用“引用”概念輕松的構(gòu)建一個(gè)多維的表示空間。在面向?qū)ο蟮募夹g(shù)背景下，x.y.z這樣的形式表示暗示著x,y,z是同時(shí)存在的。當(dāng)z發(fā)生變化的時(shí)候，通過y.z和x.y的信息傳導(dǎo)，x對(duì)象本身也發(fā)生了某種變化。
隨著web技術(shù)的流行，獨(dú)立的狀態(tài)/地址空間的存在性逐漸成為系統(tǒng)不可回避的假設(shè), "同時(shí)性"的物理約束越來越難以維持. 相對(duì)論規(guī)定了物理現(xiàn)象的定域性, 在數(shù)字空間我們一直忽視了它.但有趣的是, 網(wǎng)絡(luò)上的傳輸時(shí)延卻迫使我們重新發(fā)現(xiàn)了"引用"形式下必然存在著的物理過程. 引用本身只是標(biāo)記了某種信息關(guān)聯(lián), 并不一定意味著同時(shí)性約束. 并發(fā)編程領(lǐng)域的所謂的Future對(duì)象是對(duì)傳統(tǒng)引用概念的一種有趣擴(kuò)展.
result = obj.callMethod(args) ==> future = obj.callMethod(args)
future對(duì)象可以被自由傳遞, 只有當(dāng)實(shí)際訪問到它的屬性的時(shí)候, 才會(huì)觸發(fā)時(shí)序約束.
判斷和循環(huán)是程序中最基本的語句結(jié)構(gòu)。而在vonNeumann體系架構(gòu)下，循環(huán)是對(duì)集合進(jìn)行操作所需的基本步驟。一個(gè)有趣的事實(shí)是，函數(shù)式語言所宣稱的
生產(chǎn)力的來源很大程度上在于集合操作的便捷性。在數(shù)學(xué)中我們通過張量分析，泛函分析等可以清楚地意識(shí)到集合之間的相互作用是可抽象的，是可以獨(dú)立理解的，
即我們可以在不涉及具體基元結(jié)構(gòu)的層面上獨(dú)立的定義并執(zhí)行集合運(yùn)算。如何將這種概念獨(dú)立性在框架層面展開是一個(gè)非常深刻的命題。
在基元結(jié)構(gòu)上應(yīng)用基礎(chǔ)操作p(d)這一微觀場(chǎng)景一般情況下是容易理解并實(shí)現(xiàn)的, 但通常程序中所定義的大量邊界是基于集合變量的,
因此很多代碼都是封包和解包操作, 在層層嵌套的循環(huán)結(jié)構(gòu)深處我們才能發(fā)現(xiàn)真正具有業(yè)務(wù)價(jià)值的基元結(jié)構(gòu).
將集合操作提升到系統(tǒng)層，減少或簡(jiǎn)化在應(yīng)用層需要顯式編制的循環(huán)結(jié)構(gòu)是框架設(shè)計(jì)層面需要考慮的問題.
一個(gè)最基本的方法是盡量定義通用的同構(gòu)操作, 避免構(gòu)造中間集合. 例如前后臺(tái)之間通過json等通用協(xié)議交換復(fù)雜結(jié)構(gòu)的對(duì)象,
避免定義特殊的中間處理過程. 一個(gè)與之相配合的重要技術(shù)手段是通過類查詢語句(描述方式)直接構(gòu)造特定的集合.
例如prototype.js中提供的$$('div
div.myclass').each(op)這樣的處理方式顯然要比在循環(huán)過程中基于特定條件過濾要方便的多.
而在AOP操作中切點(diǎn)的集合定義方式也是其提供的核心價(jià)值之一. 與集合操作相適應(yīng)的一種代碼風(fēng)格是流式設(shè)計(jì)(stream),
這正是jQuery試圖鼓吹的主要價(jià)值(雖然我個(gè)人認(rèn)為它有些走極端). 流式設(shè)計(jì)的核心結(jié)構(gòu)實(shí)際上是 x += dx,
它不需要集合是一次性構(gòu)造的, 便于支持一種逐步部分修正的概念模型.
為了支持集合的隱式構(gòu)造, 我們需要以通用的方式定義元素到集合的組裝規(guī)則.
在Witrix平臺(tái)的前臺(tái)js框架中我們定義了由獨(dú)立的html組件到復(fù)合查詢條件的拼接規(guī)則,
定義了由每個(gè)html組件的數(shù)據(jù)校驗(yàn)函數(shù)到整個(gè)form的數(shù)據(jù)校驗(yàn)函數(shù)之間的組裝規(guī)則,
定義了由單個(gè)html組件提交參數(shù)到整個(gè)form提交參數(shù)之間的組裝規(guī)則. 在Witrix平臺(tái)的標(biāo)準(zhǔn)界面上,
框架本身的編制基于js.query.buildCondition(frmQuery),
js.validate.validateForm(frmUpdate), ajax.addForm(frmUpdate)等少量集合操作進(jìn)行,
在不同的應(yīng)用場(chǎng)景下, 我們只需要關(guān)心每一個(gè)字段如何顯示, 提交哪些屬性, 而由系統(tǒng)負(fù)責(zé)將它們自動(dòng)組裝并在后臺(tái)進(jìn)行分派. 面向不同的應(yīng)用,
框架代碼不需要做出任何修改, 確保了系統(tǒng)結(jié)構(gòu)的可重用性.
Witrix平臺(tái)的后臺(tái)處理模型中定義了實(shí)體化過程, DaoWebAction基于CRUD等原子操作定義了批量提交,
數(shù)據(jù)導(dǎo)入導(dǎo)出等復(fù)合的甚至是嵌套的集合操作. 在不同的應(yīng)用中, 我們通過修改bizflow文件中<action
id="ViewDetail-default">, <action
id="Update-default">等針對(duì)單實(shí)體的業(yè)務(wù)規(guī)則即可適應(yīng)不同的業(yè)務(wù)場(chǎng)景, 而不需要為特定的應(yīng)用重復(fù)編制集合處理過程.
面向集合+通用組裝規(guī)則是Witrix平臺(tái)設(shè)計(jì)中采用的基本設(shè)計(jì)手法之一,
它使得我們?cè)谝话銘?yīng)用中只需要考慮單實(shí)體,單字段等基元結(jié)構(gòu)上發(fā)生的特定業(yè)務(wù), 大大簡(jiǎn)化了系統(tǒng)構(gòu)造過程.
但是也需要認(rèn)識(shí)到從個(gè)體到集合的擴(kuò)張(p(d) -> P(D) )是非平凡的, 集合比個(gè)體的簡(jiǎn)單加和要更多,
為此架構(gòu)中需要保留對(duì)集合邊界的識(shí)別能力, 例如需要允許在數(shù)據(jù)導(dǎo)入完成之后執(zhí)行特定的業(yè)務(wù)規(guī)則而不是僅僅針對(duì)每一數(shù)據(jù)行執(zhí)行業(yè)務(wù)規(guī)則.
由于各個(gè)公司的領(lǐng)域，規(guī)模，人員配備等差異很大，形形色色的公司中頂著架構(gòu)師頭銜的諸般人等所從事工作的內(nèi)容以及所承擔(dān)的責(zé)任也是大相徑庭。務(wù)虛者有之，務(wù)實(shí)者也有之, 難以一概而論。甚至關(guān)于架構(gòu)一詞的具體含義在不同語境下也是很難達(dá)成共識(shí)的。然而作為架構(gòu)師，他應(yīng)該做什么，能夠做什么，卻是我在自己的職業(yè)生涯中需要加以回答的問題。
軟件公司中的工作大致分為銷售，技術(shù)，財(cái)務(wù)，打雜這幾類。架構(gòu)師所從事的工作大致上屬于技術(shù)這一攤，應(yīng)該是一種高度專業(yè)化的技術(shù)工作。在我看來，一般所謂架構(gòu)師的工作主要是負(fù)責(zé)設(shè)計(jì)規(guī)范整個(gè)軟件項(xiàng)目/產(chǎn)品/產(chǎn)品線的整體結(jié)構(gòu)，他所擺弄的是各種相關(guān)的技術(shù)元素。雖然作為公司的技術(shù)利益的代表者，架構(gòu)師會(huì)在某種程度上參與到公司的商業(yè)活動(dòng)中（在某些巨型公司中，架構(gòu)師甚至可以通過標(biāo)準(zhǔn)規(guī)范對(duì)整個(gè)產(chǎn)業(yè)結(jié)構(gòu)施加影響），但是他更多的是接收商業(yè)需求將其轉(zhuǎn)化為技術(shù)約束，而很少是商業(yè)目標(biāo)的制定者。業(yè)務(wù)架構(gòu)方面的設(shè)計(jì)更理想的是由業(yè)務(wù)專家進(jìn)行，這個(gè)工作多半只需要技術(shù)的常識(shí)，而不需要對(duì)于技術(shù)本身的深刻洞察。在另一方面，雖然架構(gòu)師對(duì)于技術(shù)實(shí)現(xiàn)所需的技術(shù)/人力等資源需求會(huì)提出自己的估算和建議，但是他一般并不具備相應(yīng)的手段和責(zé)任來具體管理整個(gè)實(shí)現(xiàn)過程。因此在我看來架構(gòu)師的管理職責(zé)并不是很大。當(dāng)然，有些架構(gòu)師會(huì)更加接近商業(yè)和管理而遠(yuǎn)離技術(shù)，將他們稱之為"資深架構(gòu)師"可能更加合適。在某些大型系統(tǒng)的建設(shè)過程中，總體設(shè)計(jì)人員可以只負(fù)責(zé)收集各個(gè)子系統(tǒng)的技術(shù)要求，匯總后制定整體技術(shù)規(guī)范，所起的作用類似于協(xié)調(diào)人員，在這種情況下倒是對(duì)技術(shù)要求較低而對(duì)管理素質(zhì)要求較高了。
關(guān)于架構(gòu)的一個(gè)有趣的事實(shí)是，技術(shù)架構(gòu)本身其實(shí)很少存在設(shè)計(jì)問題。大部分問題只在于業(yè)務(wù)問題如何分解到既定的技術(shù)架構(gòu)上，一般的技術(shù)架構(gòu)也只是現(xiàn)有技術(shù)元素的簡(jiǎn)單組合而已。所謂的架構(gòu)設(shè)計(jì)工作并不是在真正的系統(tǒng)全景下進(jìn)行，它往往是基于已有經(jīng)驗(yàn)所作的短暫延伸，是對(duì)業(yè)內(nèi)其他類似結(jié)構(gòu)的復(fù)制變形。我們所面臨的大量問題是選型問題，不是創(chuàng)造性問題，而是選擇性問題。架構(gòu)師最富技巧性的工作不是現(xiàn)在確定什么，做出選擇，而是確定現(xiàn)在可以不確定什么，可以將哪些選擇延遲。
在一般人看來，架構(gòu)師對(duì)于系統(tǒng)成敗必然起著關(guān)鍵性作用，否則他們憑什么屬于“活少錢多”的那伙人呢。但真實(shí)情況是，商業(yè)上的成敗很少是由技術(shù)架構(gòu)直接決定的。因?yàn)榧夹g(shù)開放和快速傳播等原因造成了技術(shù)的趨同性，在技術(shù)層面上，大多數(shù)公司很難依靠技術(shù)形成差異化優(yōu)勢(shì)。競(jìng)爭(zhēng)優(yōu)勢(shì)主要來源于業(yè)務(wù)理解和與用戶的接觸性，來自于歷史形成的業(yè)務(wù)格局。而在中國(guó)這樣一個(gè)營(yíng)銷制導(dǎo)的商業(yè)世界中，架構(gòu)師的工作更難說是在構(gòu)造某種與眾不同的東西。只有少數(shù)大公司依靠把握標(biāo)準(zhǔn)才形成技術(shù)的話語權(quán)，大部分人不過是在技術(shù)的大潮中隨波逐流罷了。“不求有功，但求無過”應(yīng)該是架構(gòu)師基本的工作精神。技術(shù)失敗最常見的原因除了不夠?qū)I(yè)以外（在中國(guó)，“專業(yè)”的標(biāo)準(zhǔn)也許是不同的），就是過于自信，試圖去創(chuàng)造些新的結(jié)構(gòu)，或者試圖全面應(yīng)用某種不熟悉的技術(shù)。架構(gòu)建設(shè)應(yīng)該是一個(gè)逐步改進(jìn)的過程，不要激進(jìn)盲動(dòng)。
國(guó)內(nèi)的架構(gòu)師多數(shù)是從高級(jí)程序員發(fā)展而來，在工作期間多半是學(xué)習(xí)掌握外部知識(shí)，以掌握知識(shí)的細(xì)節(jié)程度和廣度為優(yōu)先。因?yàn)榭偸窃趧e人搭好的平臺(tái)上活動(dòng)，即使是參與過眾多大型系統(tǒng)的建設(shè)，對(duì)于系統(tǒng)整體結(jié)構(gòu)一般也沒有提煉出自己的認(rèn)識(shí)觀點(diǎn)。而有些大學(xué)設(shè)置了專業(yè)，宣傳培養(yǎng)架構(gòu)師，但是實(shí)際上缺乏系統(tǒng)的實(shí)踐訓(xùn)練，學(xué)生所學(xué)到的多半是高舉高打的套路，在實(shí)戰(zhàn)中的表現(xiàn)往往更差。掌握技術(shù)細(xì)節(jié)和自主的整體性思考對(duì)于架構(gòu)師而言都是不可或缺的。
雖然創(chuàng)新的技術(shù)未必是商業(yè)中核心的元素，但是真正的創(chuàng)造性仍然是每一個(gè)設(shè)計(jì)師的希冀。作為一名實(shí)踐者，我們都在某種程度上期望超越所經(jīng)歷的偶然，達(dá)到某種普遍的真理，在外部的物質(zhì)世界中留下自己的精神烙印。在這種意義下，架構(gòu)師的工作便不是簡(jiǎn)單的技術(shù)背景或者技術(shù)理解可以涵蓋的了。我相信，在業(yè)務(wù)層和基礎(chǔ)技術(shù)設(shè)施之間存在著物理性的厚重的通用技術(shù)層，其中存在著大量的結(jié)構(gòu)規(guī)律等待我們的探索，這也正是Witrix平臺(tái)一直努力的方向。
我們總認(rèn)為認(rèn)識(shí)的最高境界是認(rèn)識(shí)到事物的本質(zhì)。但是越明晰的認(rèn)識(shí)意味著越明晰的區(qū)分，而區(qū)分意味著認(rèn)識(shí)到事物的獨(dú)特性，割裂了它與普遍事實(shí)之間的聯(lián)系。我們是否會(huì)說這一本質(zhì)和那一本質(zhì)是本質(zhì)上不同的？本質(zhì)最根本的意義在于內(nèi)在的規(guī)律，在于內(nèi)在的協(xié)調(diào)而不是和普遍事物的對(duì)立。我們對(duì)本質(zhì)的認(rèn)識(shí)是如何成為可能的？現(xiàn)代語言哲學(xué)發(fā)掘的一個(gè)基礎(chǔ)事實(shí)是我們的語言中涉及到抽象事物的部分存在含混性和自我證明的邏輯循環(huán)。在抽象的概念上我們很難達(dá)到共識(shí), 而這恰恰是通常我們認(rèn)為所謂本質(zhì)所寄居的地方. 語言文字是人類所創(chuàng)造的思維的工具，我們對(duì)它們的存在早已習(xí)以為常。只有研究詞源的時(shí)候, 我們才能清楚地意識(shí)到人們的思維和世界的現(xiàn)象之間的巨大鴻溝. 通過千百年的文化積淀和不斷的自我強(qiáng)化, 我們才形成了共同的民族心理結(jié)構(gòu), 看到同樣的文字的時(shí)候才能激發(fā)我們類似的情感, 才能引起類似的意向，但是具體的過程仍然是不可言說的.
辯證法的兩端都能夠成為我們認(rèn)識(shí)的對(duì)象，因此我們會(huì)感到矛盾對(duì)立的存在. 但是隨著我們認(rèn)識(shí)方向的轉(zhuǎn)移, 很多矛盾可能被弱化,被消解. 在本世紀(jì)初, 相對(duì)論和量子論無論在理智或者情感上都是如此讓人難以接受, 但是新一代的學(xué)生接受起來已經(jīng)自然了很多. 現(xiàn)在我們只需要盲目的遵守規(guī)則,而不再需要去尋求自我證明的解釋. 在現(xiàn)代物理的框架下, 慣性不是物質(zhì)本身的屬性, 它來自物質(zhì)之外. 萬有引力不是物質(zhì)之間的額外的相互作用,而是時(shí)空扭曲后造成的內(nèi)蘊(yùn)約束. 但是在局部情況下, 并不妨礙我們建立一個(gè)形式系統(tǒng)使得這個(gè)屬性內(nèi)在化。在很多時(shí)候只有偏執(zhí)的認(rèn)識(shí)才能引導(dǎo)我們穿越未知.
中國(guó)人的認(rèn)識(shí)論是整體性的，但卻不是公理化的.傳統(tǒng)上我們說微言大義，總試圖從真切的細(xì)節(jié)處領(lǐng)悟超越的真理. 這是和分析法不同的認(rèn)識(shí)的途徑, 但也很難說它是歸納法. 思維中的意象是符號(hào)化的, 但是也是具體的，擁有自己的形象，并具有某種潛在的活動(dòng)性。
讀書在傳統(tǒng)意義上是走向精英階層的一條路徑，這種功利目的一直深刻在我們的心中。學(xué)校也是按照培養(yǎng)高于平均水平之上的人才而設(shè)定的。只是在如今這個(gè)人人都是大學(xué)生的時(shí)代，大學(xué)生早已不是什么“天之驕子”。缺乏可以用于創(chuàng)造或者交換的技能和資源，知識(shí)階層的相對(duì)貶值也在情理之中。依然持有著自己應(yīng)該高于普通生活水平的錯(cuò)覺，非要在面子上有所交待，負(fù)擔(dān)高于平均水準(zhǔn)的車/房，很多時(shí)候只是徒增煩惱而已。
讀書是獲取知識(shí)的主要途徑，即使在影音世界空前繁榮的今天，它仍然是不可替代的。不知是學(xué)生的問題，老師的問題，抑或是整個(gè)教育機(jī)制的問題，現(xiàn)在接觸到的很多人既沒有從學(xué)校學(xué)習(xí)到必要的知識(shí)，也沒有掌握基本的學(xué)習(xí)方法。很多人津津樂道的是某某很聰明，沒見他用功也取得好成績(jī)，某某很能來事，沒干多久就掙了大錢之類的傳聞。不勞而獲可以是一種希望，卻很難成為發(fā)生在自己身上的現(xiàn)實(shí)。我見過的聰明人很多，但是真正能做出一些自己的東西的人，都具備某種專注的能力，都要在某個(gè)方向上做出一般人難以達(dá)到的持久的努力，所付出的成本往往是不為人所知的。
學(xué)習(xí)沒有捷徑，但卻是有方法的。有效的閱讀需要在一定的時(shí)間內(nèi)完成，在最短的時(shí)間內(nèi)獲得整體的階段性的認(rèn)識(shí)。太厚或者太過艱難的書會(huì)耗盡我們的耐心。循序漸進(jìn)，舉一反三，溫故知新是平凡的真理。讀書一定要做筆記, 否則所獲得的印像很快就會(huì)因?yàn)闆]有物質(zhì)憑依而消逝. 筆記不是抄書，而是從自己的視角重新整理并組織，一般最多兩三頁紙而已。不要糾纏在文字細(xì)節(jié)上, 而要努力把握其中的一種圖景. 物理中非常強(qiáng)調(diào)物理圖象的重要, 這些圖象未必是仿真的, 未必是要把事實(shí)世界中的事情復(fù)原，它們更多的是符號(hào)性的, 所指向的是一種感覺。有些人總是糾纏在什么是OOA, 什么是OOD這樣的概念區(qū)分上，但是多數(shù)時(shí)候這些區(qū)分都是毫無意義的。我們需要脫離紙面上的圖形和文字，想象它們的真實(shí)，這絕不是UML那種已經(jīng)定義了的符號(hào), 而是與世界上更多事物可以發(fā)生共鳴的某種形式. 我們所需要的是利劍迎面擊來的那一剎那間對(duì)它最直接的感受. 思考問題的時(shí)候是現(xiàn)在這種感覺和曾經(jīng)想過或者曾經(jīng)看過的其他問題的相似, 而不涉及到任何文字上嚴(yán)謹(jǐn)?shù)谋硎? 很多書上都列出很多條規(guī)則, 但是誰能保證這些規(guī)則是完備的, 如何才能從唯一的規(guī)則實(shí)現(xiàn)逐步的分化, 將它們演變出來. 能不能采用自己的語言復(fù)述, 能不能找出一個(gè)特定的視角重建這些概念的關(guān)聯(lián). 當(dāng)把信息抽離到少數(shù)符號(hào)的時(shí)候, 通過空間形象思維我們有可能把握這一點(diǎn). 空間優(yōu)于時(shí)間, 實(shí)際上對(duì)于時(shí)間的感受我們是通過空間運(yùn)動(dòng)來定義的.
現(xiàn)在的世界與百年之前已經(jīng)是有著本質(zhì)的區(qū)別，知識(shí)成為公開市場(chǎng)上兜售甚至免費(fèi)公開的東西。在前所未有的開放中，人人都具有了創(chuàng)造的可能，所謂的創(chuàng)意早已成為我們慣常的生活，以至于一階變化已經(jīng)無法稱其為真正的創(chuàng)造了。但另一方面，真正的思想仍然具有本質(zhì)的稀缺性。原創(chuàng)的思想往往來自于少數(shù)人，其他人往往是在某一方向上進(jìn)行衍生。現(xiàn)在很多人已經(jīng)習(xí)慣了快餐式的文化消費(fèi)，卻不知更應(yīng)該去閱讀大師的原著而不是經(jīng)過別人蒸餾后的轉(zhuǎn)述。原創(chuàng)的思想在文字中躍動(dòng)，它所關(guān)注的不僅是眼前的事實(shí)，而是整個(gè)世界和當(dāng)前事實(shí)之間的關(guān)聯(lián)，試圖為它尋求到真正存在的價(jià)值。
讀書是一件有趣的事情，但是將一切都?xì)w結(jié)于某種感官的快樂，無疑是一種過分淺薄的觀念。讀書之樂趣未必是真的愉悅的感受。
讀書不能使你更加富有,也不一定能帶給你安寧, 不一定對(duì)你的工作生活有什么幫助. 它只是Kill Time的一種方式而已. 只是相對(duì)于電視影像的強(qiáng)制傾銷, 游戲競(jìng)技的自我沉迷, 它比較適中的維持了一定的自主性和外部性的平衡. 我常說, 讀書只是使你明白自己生活在怎樣的一個(gè)時(shí)代, 自己不是一個(gè)蒙昧的原始人. 不清楚相對(duì)論, 不知道量子力學(xué), 不了解基因技術(shù), 只是很遺憾的在二十一世紀(jì)走過.
讀書也是讀書人在社會(huì)上得以自持的一種方式，因?yàn)楫吘刮覀冞€可以說：拽什么拽，沒文化，不稀的理你。
雖然現(xiàn)代物理的標(biāo)準(zhǔn)表述采納了嚴(yán)密的數(shù)學(xué)語言，物理學(xué)和數(shù)學(xué)的精神還是有著深刻區(qū)別的。數(shù)學(xué)的目標(biāo)在于在既定的范圍內(nèi)把有限規(guī)則的推理推進(jìn)到極致。物理學(xué)格物以致知，我們所了解到的永遠(yuǎn)只是這個(gè)世界變化的部分。當(dāng)一種物理機(jī)制位于我們的視野之外時(shí)，物理學(xué)將選擇直接無視它。因此物理學(xué)對(duì)數(shù)學(xué)是按需使用的，是有限理性的，總要受到所謂物理直觀的制約。再完美的物理模型也不過是在不完全信息下建立的一種完備的數(shù)學(xué)模型。當(dāng)我們沿著一條推理的鏈條越走越遠(yuǎn)的時(shí)候，一種本能的懷疑便會(huì)油然而生。
Witrix開發(fā)平臺(tái)基于級(jí)列設(shè)計(jì)理論發(fā)展了一系列新的設(shè)計(jì)思想和軟件分解機(jī)制。并提出了一種新的Web體系架構(gòu)。 http://canonical.javaeye.com/blog/33824
Witrix架構(gòu)呈"可"字形態(tài)，其中定義了三條主要的分界線:
1. 瀏覽器和服務(wù)器之間通過語義結(jié)構(gòu)明晰的URL形成兩分結(jié)構(gòu)。 http://canonical.javaeye.com/blog/99122
2. 系統(tǒng)前臺(tái)至后臺(tái)存在一條預(yù)制的非侵入的信道. 它維持了一種無害的可擴(kuò)展結(jié)構(gòu).
具體的說,系統(tǒng)從前臺(tái)js到后臺(tái)處理,對(duì)于所有$為前綴的參數(shù)是自動(dòng)傳遞的,沒有識(shí)別出的層將自動(dòng)把這些參數(shù)傳遞下去.系統(tǒng)通過這一信道實(shí)現(xiàn)退化過程。在
我以前的文章中曾經(jīng)指出過， 每一種可退化形式都對(duì)應(yīng)存在一種非侵入性的可擴(kuò)展設(shè)計(jì)。 http://canonical.blogdriver.com/canonical/993807.html
3. Witrix內(nèi)置了對(duì)于CRUD模型的支持， 而BizFlow通過類似AOP的方法對(duì)CRUD模型進(jìn)行了擴(kuò)展。這使得Witrix的模型驅(qū)動(dòng)部分并不是僅僅針對(duì)單表或者單實(shí)體的維護(hù), 而是可以實(shí)現(xiàn)特定的業(yè)務(wù)邏輯和CRUD邏輯的混雜.
這三條分界線分別規(guī)范了基礎(chǔ)狀態(tài)空間，對(duì)已有知識(shí)的重用以及面向未來的可擴(kuò)展性。在這種大的宏觀結(jié)構(gòu)下，Witrix應(yīng)用了如下技術(shù)手段:
1. 對(duì)象化。Witrix中的Jsplet框架以對(duì)象的名義提供了對(duì)后臺(tái)的狀態(tài)和行為空間進(jìn)行分解的基礎(chǔ)手段。 http://canonical.javaeye.com/blog/33873。Witrix
依托于Jsplet對(duì)象實(shí)現(xiàn)相關(guān)性的局域化, 而不需要像一般面向action的框架那樣直接訪問http session這一全局狀態(tài)空間.
前臺(tái)發(fā)送的objectName參數(shù)同時(shí)在系統(tǒng)的不同層面標(biāo)定了WebAction響應(yīng)函數(shù), Biz配置, DataSourceMeta元數(shù)據(jù),
Hibernate實(shí)體等一系列相關(guān)概念, 使得它們構(gòu)成一個(gè)統(tǒng)一的整體.
2.
標(biāo)準(zhǔn)化。與REST架構(gòu)風(fēng)格類似，DaoWebAction規(guī)范化了后臺(tái)響應(yīng)事件。DaoWebAction上支持的標(biāo)準(zhǔn)事件有Query,
ViewDetail,Add, Update, Remove等,
它們構(gòu)成一個(gè)完整的CRUD模型。與REST不同的是，DaoWebAction提供了一個(gè)空的響應(yīng)事件BizAction。它相當(dāng)于是CRUD模型中的
零元操作。在BizFlow模型下，它將被擴(kuò)展為一個(gè)操作子空間，從而實(shí)現(xiàn)對(duì)于CRUD模型的超越。而在REST模型下所有的擴(kuò)展操作必須依附于一個(gè)已經(jīng)
具有固定語義的Method上，例如POST. http://canonical.javaeye.com/blog/99122
3. 實(shí)體化。在Witrix中充分發(fā)掘了ORM技術(shù)的能力, 使得單一業(yè)務(wù)對(duì)象上可以聚集到某一范圍內(nèi)的所有相關(guān)結(jié)構(gòu)信息.
http://canonical.javaeye.com/blog/111500.
同時(shí)在DaoWebAction中通過EntityFilter機(jī)制實(shí)現(xiàn)了單實(shí)體化過程. 這意味著前臺(tái)應(yīng)用可以一次性提交多個(gè)批量操作,
后臺(tái)框架負(fù)責(zé)把它們分解為針對(duì)單個(gè)實(shí)體的一次確定性操作, 在后臺(tái)實(shí)現(xiàn)時(shí)只需要考慮單實(shí)體的情況即可.
一個(gè)簡(jiǎn)單的例子是前臺(tái)提交objectEvent=Remove&id=1&id=2&id=3 ,
WebAction層會(huì)為每一個(gè)id對(duì)應(yīng)的實(shí)體調(diào)用BizFlow中的Remove-default操作. 實(shí)體化是一個(gè)非常重要的過程,
它使我們關(guān)注的核心成為單實(shí)體, 正是因?yàn)槊鞔_了單實(shí)體作為基本的關(guān)注點(diǎn), 我們才可以建立更加復(fù)雜的狀態(tài)機(jī)機(jī)制, 驅(qū)動(dòng)系統(tǒng)狀態(tài)變化.
4. 組件化. 前臺(tái)的tpl模板和后臺(tái)的WebAction共享一個(gè)thisObj指針, 結(jié)合自定義標(biāo)簽機(jī)制, 資源(js/css等)管理機(jī)制等構(gòu)成可以重用的組件結(jié)構(gòu).
5. 偏置的AOP. BizFlow通過一種類似于AOP的操作對(duì)DaoWebAction提供的CRUD模型進(jìn)行擴(kuò)展,
使得模型的能力得到本質(zhì)性的擴(kuò)張. 這種AOP操作與通常意義的AOP的區(qū)別在于: 缺省行為在默認(rèn)情況下發(fā)生, 除非顯式禁止. 通過這種方式,
反轉(zhuǎn)了base和extension之間的主體地位. 此外BizFlow所提供的不僅僅是行為的擴(kuò)展,它同時(shí)提供了對(duì)界面的描述.
在前臺(tái)tpl頁面中通過 <ds:BizViewOps/>等無參數(shù)的標(biāo)簽調(diào)用來定義嵌入坐標(biāo). http://canonical.javaeye.com/blog/34941
與傳統(tǒng)的J2EE相比較, Witrix表現(xiàn)出很多變化:
1. 不使用全局的session, 而是使用局域化的thisObj
2. 不定義service層，其功能分解到BizFlow和Handler中，它們都不負(fù)責(zé)日常的DAO操作。獨(dú)立的MDA部分負(fù)責(zé)所有的實(shí)體CRUD(Create Read Update Delete)操作。
3. 不定義頁面跳轉(zhuǎn)規(guī)則，在前臺(tái)使用拉模式直接表明跳轉(zhuǎn)目標(biāo)。結(jié)合前臺(tái)stdPage對(duì)象在前臺(tái)控制跳轉(zhuǎn)目標(biāo)。并可以在BizFlow中配置覆蓋的規(guī)則，這樣就可以針對(duì)不同的應(yīng)用場(chǎng)景定義不同的跳轉(zhuǎn)規(guī)則。
4. 不是為每個(gè)模塊, 每個(gè)應(yīng)用場(chǎng)景編制一組新的頁面,而是大多數(shù)模塊共用少數(shù)幾個(gè)標(biāo)準(zhǔn)頁面.
5. 不在與網(wǎng)絡(luò)無關(guān)的service層上定義權(quán)限和事務(wù)管理。Witrix架構(gòu)下通過URL明確區(qū)分了系統(tǒng)內(nèi)部和外部,
前臺(tái)訪問后臺(tái)時(shí)調(diào)用者的全部意圖是以規(guī)范化的形式表達(dá)在url中的.
因此權(quán)限和事務(wù)管理作用在WebObject上在概念上也可以認(rèn)為是約束直接作用在URL上, 這與REST風(fēng)格是統(tǒng)一的.
當(dāng)然我們也可以規(guī)范service方法的命名等, 但是顯然要求一種隨意性消失是有代價(jià)的,
在URL上我們已經(jīng)付出了代價(jià),為什么要在service上再付出一次. Witrix中Transaction和Auth的配置更加直觀,
因?yàn)橐?guī)范化了WebObject上的事件響應(yīng)函數(shù),一般我們也不需要進(jìn)行特殊的配置.
Witrix這種設(shè)計(jì)更加適合于網(wǎng)絡(luò)這一兩分結(jié)構(gòu)的，更加充分的利用這一架構(gòu)邊界所提供的隔離性.
6. 不在頁面中使用實(shí)體的字段名，而是大量通過元數(shù)據(jù)表達(dá)程序意圖。http://canonical.javaeye.com/blog/114066
一般J2EE多層架構(gòu)下，所謂的架構(gòu)分解主要是對(duì)程序縱向的分解，但是程序結(jié)構(gòu)方面是沒有橫向分解的。而witrix架構(gòu)的一個(gè)核心就是橫向存在著
CRUD模型和Biz的分解。在系統(tǒng)的所有實(shí)現(xiàn)過程中，所有CRUD操作都剝離到MDA模型中，而不需要任何代碼編制。典型的,
witrix后臺(tái)代碼一般寫在handler中，命名為handler而不是service是因?yàn)閔andler中負(fù)責(zé)的內(nèi)容和j2ee傳統(tǒng)上的
service有所不同，一般service總是要負(fù)責(zé)某個(gè)實(shí)體的CRUD操作，大量的findxxx代碼。一般提倡的最佳實(shí)踐是實(shí)現(xiàn)某個(gè)通用的基類，所
有service都繼承該基類獲得CRUD能力。但是在Witrix架構(gòu)中，根本沒有這一需要。Handler只要完成自己特定的功能，它不追求操作概念
在其本身的完整性。沒有CRUD,
handler沒有意義。但是handler之所以有意義是因?yàn)樗峁┝薈RUD之外的操作。當(dāng)CRUD成為系統(tǒng)一種自動(dòng)進(jìn)行的背景操作時(shí)，我們不再需要
明確意識(shí)到它的存在。
我們需要認(rèn)識(shí)到我們最終所需要的東西可能不是規(guī)整結(jié)構(gòu)的, 它可能要求對(duì)于某個(gè)規(guī)整結(jié)構(gòu)進(jìn)行剪裁并增補(bǔ)附加元素.
但是這樣的規(guī)整結(jié)構(gòu)不應(yīng)只存在于我們的想象之中，相應(yīng)的剪裁過程應(yīng)該是可以增量進(jìn)行, 反復(fù)進(jìn)行的. 在Witrix平臺(tái)中， 基本的一種圖景變化是:
Witrix中不再需要從頭開始構(gòu)造結(jié)構(gòu), 而只要指定當(dāng)前業(yè)務(wù)和背景模型之間的差異部分.
在Witrix中所寫的業(yè)務(wù)代碼是對(duì)核心模型的擴(kuò)展。這不僅僅是概念上的，而是實(shí)際體系架構(gòu)上精確的體現(xiàn)。CRUD作為獨(dú)立的模型吸收了系統(tǒng)中大量的變
化。整個(gè)模型內(nèi)核是采用通用方式借助meta實(shí)現(xiàn)功能，并不涉及到特定于業(yè)務(wù)的類。對(duì)于那些我們已經(jīng)掌握的知識(shí),
Witrix提供了超越對(duì)象繼承,AOP和組件重用的結(jié)構(gòu)抽取手段, 使得知識(shí)可以穩(wěn)步積累.
數(shù)學(xué)中存在兩種基本的分解方式， 一種是加性分解 (a,b) + (c, d) => (a,b,c,d)， 另一種是乘性分解
(a,b) X (c, d) => (ac,bc,ad,bd)， 它也對(duì)應(yīng)于張量(Tensor)運(yùn)算. 在群論(Group
Theory)中，直積對(duì)于復(fù)雜性的化簡(jiǎn)至關(guān)重要，它的重要性要遠(yuǎn)在加和之上。實(shí)際上AOP操作類似于直積分解， 只是它的能力尚未得到充分的探索。
在Witrix中，biz的作用在感覺上很象是陪集(coset)運(yùn)算：CURD *
biz。不同的biz作用到同樣的CRUD模型上產(chǎn)生不同的操作集合，而所有biz組成的集合構(gòu)成獨(dú)立的整體。
Witrix平臺(tái)中作為內(nèi)核的MDA部分首先是物理模型驅(qū)動(dòng), 而不是邏輯模型或者對(duì)象模型驅(qū)動(dòng).
我們通過在物理模型上標(biāo)注的方法恢復(fù)部分對(duì)象模型的信息, 但是我們并不試圖把整個(gè)軟件建立為模型. 所建立的僅僅是整個(gè)程序模型的內(nèi)核.
http://canonical.javaeye.com/blog/29412 一般業(yè)內(nèi)鼓吹的所謂MDA成功的關(guān)鍵是要提高抽象層次。
但是陪集是更抽象嗎。 正規(guī)子群更抽象嗎。 它們只是系統(tǒng)的指標(biāo)性表征，使對(duì)信息的distill, 是更容易理解的一個(gè)側(cè)面而已,
抽象性并不是一個(gè)真正的目標(biāo)。很多時(shí)候我們需要的是把系統(tǒng)降維到某個(gè)子空間中，形成一種可控性。 但是這個(gè)子空間并不一定是更抽象的。
群作為基本的代數(shù)系，一個(gè)本質(zhì)特征是具有逆元。Witrix的MDA中明確定義了逆元結(jié)構(gòu)，即界面上的元素 empty =
buttonA + (-buttonA)，這一分解公式應(yīng)用到后臺(tái) OpA = Update * (-Update) *
OpA。假設(shè)我們已經(jīng)建立了結(jié)構(gòu)X, 現(xiàn)在需要建立一個(gè)與X略有不同的結(jié)構(gòu)Y
X = a + b + c
Y = a + d + c = (a + b + c) - b + d = X - b + d
雖然Y的兩種構(gòu)造方式在數(shù)學(xué)上是等價(jià)的，
但在物理上并不等價(jià)。第一種方式對(duì)原有系統(tǒng)進(jìn)行分解后再組裝，而第二種方式?jīng)]有打破原有的東西，不需要拆分。拆分總是可能存在問題的，正如你把所有電腦零
件拆裝下來再裝上很可能會(huì)發(fā)現(xiàn)多出幾個(gè)零件。一般情況下第二種方式的構(gòu)建成本要低. 特別是當(dāng)一切都糾纏在一起的時(shí)候,
一種細(xì)粒度的逆元結(jié)構(gòu)對(duì)于一種試圖重用的結(jié)構(gòu)是非常關(guān)鍵的.
可重用性的障礙不僅僅是來自于無法追加新的功能，很多時(shí)候也在于無法屏蔽原先已經(jīng)提供的功能。目前所有的設(shè)計(jì)原則都未能適時(shí)識(shí)別出逆元的重要性。所有的設(shè)
計(jì)教條其實(shí)所指的方向都是加和, 如何分解出更小的組元, 如何把它們加和在一起, 如何從細(xì)部開始進(jìn)行重新構(gòu)建,
而不是說依賴于現(xiàn)有已經(jīng)形成的宏觀結(jié)構(gòu), 如何進(jìn)行細(xì)粒度的調(diào)整. 所謂的AOP技術(shù)思考的關(guān)鍵點(diǎn)也在于如何給系統(tǒng)增加功能,
很少有人想到場(chǎng)景是為系統(tǒng)減少功能并把這種概念大規(guī)模正式應(yīng)用的, 雖然說AOP已經(jīng)在某種程度上具有了這種能力,
但是真正應(yīng)用它仍然需要對(duì)AOP進(jìn)行進(jìn)一步的詮釋. 當(dāng)然，現(xiàn)在的軟件業(yè)連基本結(jié)構(gòu)的構(gòu)造問題都沒有完全搞清楚, 更別提所謂結(jié)構(gòu)穩(wěn)定性的問題了.
從物理上說，Y = X - b +
d的分解方式具有特殊的意味。如果沒有逆元，我們必然需要分解。但是如果發(fā)掘了背景這一概念，在逆元運(yùn)算下，對(duì)背景不是分解讓其成為可見的部分，而是采用
追加的，增刪的方法對(duì)背景結(jié)構(gòu)進(jìn)行修正，則我們有可能在沒有完整背景知識(shí)的情況下，獨(dú)立的理解局部變化的結(jié)構(gòu)。即背景是透明的，知識(shí)成為局部的。
Witrix試圖提供的一種圖景是永遠(yuǎn)只寫代碼片斷，而所有的代碼片斷組合在一起又構(gòu)成一個(gè)可理解的整體。這個(gè)整體可以獨(dú)立理解，不需要額外的結(jié)構(gòu)元素。
Witrix架構(gòu)所追求的是在不完全信息下建模，不進(jìn)行整體建模。整體模型 + 不斷變化的局部修正 構(gòu)成
最終模型。平臺(tái)技術(shù)的目標(biāo)是讓一切應(yīng)該發(fā)生的自動(dòng)發(fā)生，讓一切不該發(fā)生的無法發(fā)生。這一模型的構(gòu)建并不是trivial的，在概念和實(shí)現(xiàn)方面都要作出很多
的努力。
題外：
今天中午參加同學(xué)的婚禮, 席間和一個(gè)與同方有些淵源的同學(xué)談到ezOne的現(xiàn)狀, 大致的評(píng)語是: 垃圾, 自己人也不用. 聽來也讓人有些感嘆. 中國(guó)原創(chuàng)的技術(shù)總是欺騙的代名詞, 這一斷言不應(yīng)總是得到證實(shí).
建筑學(xué)的隱喻在軟件業(yè)中一直很流行。開發(fā)軟件和建筑樓房從某種意義上說都是一種構(gòu)造過程，而建筑學(xué)的成熟無疑讓很多軟件工程師非常羨慕。Design Pattern的始作俑者坦承受到建筑學(xué)著作的影響更是讓一些人對(duì)建筑學(xué)的精深頂禮膜拜不已。不過，建筑決不只是表面上的形象/功能設(shè)計(jì)，也決不是民工就可以干的活計(jì)，在現(xiàn)代建筑設(shè)計(jì)背后是土木工程的蓬勃發(fā)展。正是框架結(jié)構(gòu)的出現(xiàn)和材料工藝的進(jìn)步才使得批量生產(chǎn)的大型現(xiàn)代建筑成為可能。
雖然建筑學(xué)有著它不為人知的復(fù)雜性的一面，但是與軟件開發(fā)相比，它也有著簡(jiǎn)單貧瘠的一面。現(xiàn)在架構(gòu)師言必稱設(shè)計(jì)模式，但是估計(jì)很少有人讀過Christopher Alexander的原著"A Pattern Language"。在Alexander的概念中，所謂的模式"describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". 關(guān)鍵在于這些模式在建筑學(xué)中往往映射為某種獨(dú)立的原子化的實(shí)體(entity), 因此可以把它們作為一種語言的基礎(chǔ)組分，構(gòu)成所謂的Pattern Language. 例如現(xiàn)在要開發(fā)一個(gè)門廊，你可以從"私家的沿街露臺(tái)(140)"開始，在"有陽光的地方(161)"做成一個(gè)"有圍合的戶外小空間(163)", 選擇"6英尺深的陽臺(tái)(167)", 保留"小路和標(biāo)志物(120)", 注意"天花高度變化(190)"和"角柱(212)"的位置，在"各式座椅(251)"的旁邊安排一個(gè)"高花臺(tái)(245)". Alexander共定義了253個(gè)模式，括號(hào)中的便是模式的編號(hào)。很明顯，物理空間的不可重入性直接規(guī)范了建筑設(shè)計(jì)空間的有限性。
在軟件設(shè)計(jì)中，類似VB/Delphi的可視化界面設(shè)計(jì)的操作過程與此類似：理想情況下界面開發(fā)基本就是用各種界面元素填滿一個(gè)Form的過程。但是軟件的一個(gè)本質(zhì)復(fù)雜性在于它的基本結(jié)構(gòu)單元是函數(shù)，而設(shè)計(jì)空間中同一個(gè)功能點(diǎn)對(duì)應(yīng)的實(shí)現(xiàn)函數(shù)的個(gè)數(shù)和形式并不存在有限性的約束，函數(shù)的組合形式也不是線性延展的。建筑基本上依賴的是靜力學(xué)，而軟件無疑需要用動(dòng)力學(xué)來刻畫。即使是界面開發(fā)，我們所關(guān)注的也決不僅僅是靜態(tài)擺放問題，而更重要的往往是界面元素動(dòng)態(tài)相關(guān)和動(dòng)態(tài)變化的問題。
在Web開發(fā)領(lǐng)域，一直有人鼓吹模仿VB/Delphi的快速開發(fā)工具，但是我并不認(rèn)為這其中的設(shè)計(jì)哲學(xué)是與軟件的本質(zhì)相匹配的。軟件中所蘊(yùn)含的無限的動(dòng)態(tài)變化不應(yīng)該僅僅通過有限的配置過程來應(yīng)對(duì)，我們需要更加強(qiáng)大的結(jié)構(gòu)抽象和結(jié)構(gòu)構(gòu)建手段。
程序中大量的工作其實(shí)都是在定義結(jié)構(gòu)以及結(jié)構(gòu)之間的關(guān)系. 一般情況下我們應(yīng)該識(shí)別出結(jié)構(gòu),并把它們封裝到函數(shù),對(duì)象和組件中去. 但是封裝并不永遠(yuǎn)都是有利的. 將某個(gè)結(jié)構(gòu)獨(dú)立出來, 在某種程度上也就割裂了它和其他元素之間的關(guān)系, 這會(huì)引發(fā)結(jié)構(gòu)融合的障礙, 也會(huì)造成思維上的負(fù)擔(dān). 事實(shí)上如果程序整體具有足夠的可理解性和概念穩(wěn)定性, 我們并不需要獨(dú)立識(shí)別出什么子部分. 一個(gè)簡(jiǎn)單的例子是數(shù)組循環(huán). 一般情況下我們應(yīng)該盡量把循環(huán)查找等操作封裝到函數(shù)中, 避免多重循環(huán)嵌套時(shí)產(chǎn)生過于復(fù)雜的代碼塊. 但是如果數(shù)組或者語言本身提供了each, map等函數(shù)式操作符,則這種封裝需求就大大減弱了.
隨著系統(tǒng)結(jié)構(gòu)的日益復(fù)雜化, 在系統(tǒng)中會(huì)積累大量的背景知識(shí).此時(shí)當(dāng)我們需要完成一個(gè)功能的的時(shí)候, 往往不再需要指定所有的信息, 而只需要指定背景知識(shí)之外的部分信息即可. 例如在界面上通過一個(gè)分頁表格來顯示實(shí)體列表這樣一個(gè)功能, 在Witrix平臺(tái)中通過模型驅(qū)動(dòng)的標(biāo)準(zhǔn)頁面即可自動(dòng)完成. 一般的定制需求往往是過濾顯示部分?jǐn)?shù)據(jù), 在表格行上增加一些操作按鈕, 定制表格的表頭等. Witrix平臺(tái)實(shí)現(xiàn)這些需求并不需要封裝出一個(gè)獨(dú)立的表格組件, 調(diào)用它的屬性修改方法等, 而是把定制部分嵌入到BizFlow的配置中, 這里并沒有明確的結(jié)構(gòu)界限.
<biz id="default">
<filter>
<eq name="status" value="1" />
<filter>
<tpls>
<tpl id="thead>
<thead>
<tr rowspan="2">...</tr>
<tr>...</tr>
</thead>
</tpl>
<tpl id="rowOps">
<ui:FlatButton .../>
</tpl>
</tpls>
其他與表格無關(guān)的信息
</biz>
注意到對(duì)于我們理解業(yè)務(wù)而言, 我們并不需要知道表格具有分頁, 排序, 隔行變色等功能. 所有和業(yè)務(wù)相關(guān)的代碼聚集到BizFlow文件中, 它們構(gòu)成一個(gè)可以獨(dú)立理解的整體, 在此過程中也通過背景知識(shí)實(shí)現(xiàn)了大量結(jié)構(gòu)的消解.
傳統(tǒng)上報(bào)表引擎主要完成兩項(xiàng)工作：結(jié)構(gòu)描述和結(jié)構(gòu)轉(zhuǎn)換。一般報(bào)表設(shè)計(jì)人員通過可視化設(shè)計(jì)工具完成對(duì)報(bào)表結(jié)構(gòu)的描述，然后報(bào)表引擎根據(jù)這些描述生成不同格式的報(bào)表文件，如PDF格式，XLS格式等。這一圖景中報(bào)表設(shè)計(jì)工具扮演著關(guān)鍵角色，因?yàn)樗粌H僅是向用戶提供一個(gè)直觀的界面，更重要的是配置過程本身就是一種分步驟的結(jié)構(gòu)構(gòu)造過程。理想的情況是用戶指定報(bào)表中具體有哪些單元格，表格具體有哪些列，而在運(yùn)行期報(bào)表引擎負(fù)責(zé)向單元格中填充數(shù)據(jù)。但是對(duì)于設(shè)計(jì)期只能進(jìn)行動(dòng)態(tài)描述，無法預(yù)先確定所有結(jié)構(gòu)元素的報(bào)表（例如交叉表的列只能在執(zhí)行時(shí)確定），這種報(bào)表模型就會(huì)出現(xiàn)問題。一般處理方式都是在報(bào)表引擎中內(nèi)置所有可能的動(dòng)態(tài)報(bào)表模型。無論設(shè)計(jì)工具多么復(fù)雜，其內(nèi)置的原理如果是基于靜態(tài)結(jié)構(gòu)模型，就無法建立一種抽象機(jī)制，這樣我們就只能通過重復(fù)勞動(dòng)來應(yīng)對(duì)眾多結(jié)構(gòu)類似但是略有不同的報(bào)表。
Witrix平臺(tái)的報(bào)表引擎是對(duì)程序友好的，它引入了編譯期結(jié)構(gòu)運(yùn)算，在報(bào)表編譯時(shí)可以通過程序吸收大部分結(jié)構(gòu)差異性。在Witrix平臺(tái)中，報(bào)表制作分為三個(gè)階段：設(shè)計(jì)期 -> 編譯期 -> 運(yùn)行期。報(bào)表引擎負(fù)責(zé)完成三種工作：結(jié)構(gòu)描述，結(jié)構(gòu)生成和結(jié)構(gòu)轉(zhuǎn)換。具體實(shí)現(xiàn)動(dòng)態(tài)結(jié)構(gòu)生成的過程其實(shí)非常簡(jiǎn)單。目前所有的Witrix配置文件都通過基礎(chǔ)配置引擎進(jìn)行解析，它定義了統(tǒng)一的dynamic和extends元機(jī)制。
<report dynamic="true">
定義了dynamic="true"的報(bào)表定義文件首先作為tpl模板文件來運(yùn)行，其運(yùn)行結(jié)果再作為報(bào)表格式解析。在這種模型下，報(bào)表引擎并沒有內(nèi)置如何把動(dòng)態(tài)結(jié)構(gòu)拼接出來的知識(shí)，這些知識(shí)存在于編譯期，而tpl標(biāo)簽的抽象能力使得我們可以把復(fù)雜的報(bào)表結(jié)構(gòu)生成過程抽象成簡(jiǎn)單的標(biāo)簽調(diào)用形式。
<report dynamic="true">
<body>
<table>
<thead>
<c:forEach var="_h" items="${cols}">
....
</table>
</body>
</report>
==>
<report dynamic="true">
<body>
<rpt:GenCrossTable tableMeta="${tableMeta}" loopVar="tableData" />
</body>
</report>
在編譯期通過tpl封裝可以解決大部分結(jié)構(gòu)生成問題，在運(yùn)行期報(bào)表引擎主要負(fù)責(zé)的結(jié)構(gòu)問題就簡(jiǎn)化為數(shù)據(jù)行展開和單元格合并等確定操作。
Witrix報(bào)表引擎的另一個(gè)特點(diǎn)是運(yùn)行期結(jié)構(gòu)生成過程和結(jié)構(gòu)轉(zhuǎn)換過程同時(shí)進(jìn)行，因此不需要在內(nèi)存中構(gòu)造一個(gè)完整的報(bào)表數(shù)據(jù)對(duì)象，大大減輕了內(nèi)存壓力。Witrix報(bào)表引擎輸出的文件格式目前有html, XML格式的Word文件和XML格式的Excel文件等。每一種輸出格式相當(dāng)于定義了一種渲染模型，它們都是對(duì)報(bào)表模型的一種展現(xiàn)方式。從某種程度上說這些模型的結(jié)構(gòu)都是等價(jià)的，但是完成模型轉(zhuǎn)換所需要的操作往往不是局域化的。例如在html的table中某一單元格具體對(duì)應(yīng)哪一列是受到其他單元格的rowspan和colspan屬性影響的, 在Excel中則需要明確指定列的index屬性。為了簡(jiǎn)化運(yùn)行期邏輯，內(nèi)置的報(bào)表模型必須提供一些冗余結(jié)構(gòu)，從而兼容多種渲染模型。
|