canonical

目前我們主要基于witrix研發(fā)行業(yè)軟件，本身并無意推廣witrix平臺(tái)。現(xiàn)在witrix所承載的核心應(yīng)用對(duì)它的靈活性和性能都有著很高的要求。
1. witrix技術(shù)的創(chuàng)新之處在于提供了程序結(jié)構(gòu)的新的抽象和融合方式，它所帶來的價(jià)值主要是程序的持續(xù)改進(jìn)能力。在公司里我們是嚴(yán)禁拷貝粘貼的。可以重用的業(yè)務(wù)邏輯總可以抽象為某種技術(shù)實(shí)體。
2. domain specific的語法我們認(rèn)為非常重要。很多人傾向于使用非常強(qiáng)大的語言，這種語言允許構(gòu)造所有復(fù)雜的局部結(jié)構(gòu)，但是在我們看來，再?gòu)?fù)雜的通用語言也無法涵蓋各異的業(yè)務(wù)邏輯，而語言本身提供的抽象能力至關(guān)重要。同時(shí)我們還非常關(guān)注于抽象出的技術(shù)結(jié)構(gòu)的穩(wěn)定性。假如做一件事情有n種語義等價(jià)的方式，而且沒有一種強(qiáng)制手段可以進(jìn)行形式校驗(yàn)，則任何一種抽象得到的結(jié)構(gòu)都是不穩(wěn)定的，因?yàn)槲覀兛偸菚?huì)受到各種誘惑偏離一種固定的形式，最終造成形式的解體。
3. 我們?cè)诰幾g期作了很多工作，這是解決系統(tǒng)結(jié)構(gòu)問題的一種重要手段。在沒有得到全部信息的情況下（沒有運(yùn)行時(shí)的數(shù)據(jù)信息），即使沒有類型概念，我們?nèi)匀豢梢栽诮Y(jié)構(gòu)方面作很多文章。
4. 現(xiàn)在很多情況下其實(shí)是沒有很好的抽象方式。比如說，如果把位圖的每個(gè)像素都看作一個(gè)具有自我活動(dòng)能力的對(duì)象，我們遇到的問題首先是巨大的管理成本，這遠(yuǎn)不如把它看作只接受外部控制的數(shù)據(jù)信息更直觀，更簡(jiǎn)單。一些所謂優(yōu)雅的設(shè)計(jì)只是在最模糊的印象上似乎很時(shí)尚， 但是真正細(xì)致到細(xì)節(jié)的時(shí)候，它遠(yuǎn)不能提供我們所需要的結(jié)構(gòu)控制能力。
5. 代碼是交流的重要工具。witrix設(shè)計(jì)的一個(gè)重要目標(biāo)就是代碼的可描述性，編碼的過程就是描述系統(tǒng)結(jié)構(gòu)的過程。我們正在盡力縮小需求描述與代碼結(jié)構(gòu)之間的概念差距。但是很多時(shí)候代碼是信息不完全的，有些信息我們寫在了代碼之外的文檔中，特別是一個(gè)設(shè)計(jì)的原因是什么，為什么采用當(dāng)前的處理方式。
6. AOP的原始形式存在一些隱蔽的問題，直接應(yīng)用AOP效果是有限的。在witrix中我們是對(duì)AOP的概念體系進(jìn)行了補(bǔ)充，才定義出足夠強(qiáng)大的結(jié)構(gòu)組合方式。
7. 對(duì)程序員來說代碼更加便捷，但是工具仍然是有效的，它可以限制程序的可能性，大大提高我們構(gòu)造某種業(yè)務(wù)流程的可靠性。
8. 商業(yè)是一方面，人的精神和傳統(tǒng)是另一方面。
9. witrix目前就在運(yùn)行時(shí)管理著大量的代碼版本，繼承只是一種初級(jí)的結(jié)構(gòu)融合手段。

對(duì)設(shè)計(jì)有興趣的朋友可以通過 canonical.cqh@gmail.com聯(lián)系我

我是在講語言，講的卻是語言之外還有別的

我一直在講物理，你現(xiàn)在來和我講數(shù)學(xué)。。。

描述和解決能是一回事嗎? 我寫下一個(gè)方程,這叫描述. 求出它的解, 這叫解決.

sign, 很遺憾你這么想問題。 我在很認(rèn)真的回答你的問題。因?yàn)檫@個(gè)問題有多個(gè)人問過我，所以寫一篇文章。

我的專業(yè)是物理。在我本科的時(shí)候，我主要在讀更多的物理和數(shù)學(xué)，而不是掌握具體的語言技術(shù)。 大四的時(shí)候我讀了圖書館可以找到的大部分C++書籍。當(dāng)然我更多的時(shí)間仍然是花費(fèi)在數(shù)學(xué)和物理上，因?yàn)樵疚揖褪谴蛩闳プ隼碚撐锢硌芯康摹?

我的意思是基礎(chǔ)很重要。大三之前都是學(xué)習(xí)最基礎(chǔ)知識(shí)的時(shí)候，專業(yè)的限定并不是很大。在我們學(xué)校，大二各個(gè)系開的課都是類似的，只是難易，重點(diǎn)不同。 你年齡太小，還區(qū)分不出什么是真正重要的東西。 其實(shí)即使是電路分析，你搞清楚里面的物理和數(shù)學(xué)也是很有意思的。絕對(duì)不是讓你按照考試的要求學(xué)習(xí)書本上的知識(shí)。

學(xué)習(xí)并不是為了有用，它只是讓你接受教育，了解歷史上人們所做過的一些工作。

溫和的感想和例子未必是對(duì)你有用的。你還沒有受過挫折，只是一味要求別人順著你的心情。我寫的東西如果你放棄成見體會(huì)一下，也許會(huì)發(fā)現(xiàn)并不是那么差。

高手不高手并不重要，關(guān)鍵是成為別人可以信賴的人，成為一個(gè)可以解決問題的人。

1. 語言中的時(shí)間觀念這個(gè)論題絕對(duì)不是我的原創(chuàng)
2. 我一直強(qiáng)調(diào)思維的連續(xù)性。不是說"B這樣搞來搞去還是達(dá)不到A的高度"， 而是說我們?nèi)绻严到y(tǒng)的特征逐個(gè)分解，到底需要做哪些工作才能逐步增加最有價(jià)值的部分，特征聚集產(chǎn)生的增值部分又是如何顯現(xiàn)的。
3. 一種實(shí)現(xiàn)總是包容了太多的思想。思想錯(cuò)了，實(shí)現(xiàn)對(duì)了。實(shí)現(xiàn)死了，思想活著。

在Witrix中我們系統(tǒng)化的應(yīng)用[面向集合+通用組裝規(guī)則]的技術(shù)手段，大大提高了代碼的重用性

從指針到引用，雖然在C++中顯得只是寫法上的簡(jiǎn)化。但是仔細(xì)體會(huì)能夠發(fā)現(xiàn)概念層面發(fā)生的一些變化。我們不再依賴取址這個(gè)具體過程，而在某種符號(hào)化的層面上理解引用所表達(dá)的信息關(guān)聯(lián)。耦合不是一個(gè)合適的描述。

你還是不懂得

1+1=2只是個(gè)形象的說法，它可不是歌德巴赫猜想的內(nèi)容

在數(shù)學(xué)和具體工藝之間還存在著所謂的物理學(xué)，這就是Witrix設(shè)計(jì)的方向。

我想你對(duì)Witrix技術(shù)還不了解。我在blog中所闡釋的理論一般都是在Witrix中實(shí)踐了的，這些技術(shù)包括AOP動(dòng)態(tài)化，基于ORM的實(shí)體化等都是Witrix中對(duì)開發(fā)效率有重大提升的地方。 目前很多技術(shù)在業(yè)內(nèi)確實(shí)處在一種言過其實(shí)的地步，而我們?cè)诶碚摲矫嬗泻芏嗤黄疲诰唧w實(shí)現(xiàn)上也作了很多精細(xì)的調(diào)整，這才最大限度的發(fā)揮了技術(shù)的效用。

開發(fā)工具并不一定是生產(chǎn)力的主要來源

JSF技術(shù)有一些真正有價(jià)值的東西，但是根據(jù)我們的實(shí)踐，這些價(jià)值有其他更加優(yōu)雅的體現(xiàn)方式。 JSF不是必須采用JSP Tag, 但是它需要一種類似的技術(shù)，而它在架構(gòu)設(shè)計(jì)中必然要照顧到這種技術(shù)實(shí)現(xiàn)。 其實(shí)witrix中的tpl技術(shù)也是一種tag技術(shù)，只是它遠(yuǎn)比jsp tag要精致。

JSF架構(gòu)最大的問題就是開發(fā)新組件很麻煩，完全基于JSF構(gòu)建程序很繁瑣，最終提供給用戶的調(diào)用接口其實(shí)也有更加簡(jiǎn)明的方式.

關(guān)鍵正在于reference這個(gè)概念本身的分化和精細(xì)化

沒有人認(rèn)為核心對(duì)分支完全不影響，否則核心升級(jí)就沒有任何意義。只是升級(jí)是可選擇的，而且分支可以選擇整體覆蓋，即擴(kuò)展后整個(gè)流程A->B->C都屬于分支

分支版本可以是不同的產(chǎn)品，不一定是同一產(chǎn)品的不同實(shí)施版本。在設(shè)計(jì)上的要點(diǎn)就是盡量允許主系統(tǒng)升級(jí)后可以隨意覆蓋項(xiàng)目版本，因?yàn)轫?xiàng)目版本針對(duì)主版本的修改是以追加方式進(jìn)行的，即并不直接修改任何主版本的文件，而是寫在獨(dú)立的文件中，平臺(tái)負(fù)責(zé)把custom內(nèi)容和基礎(chǔ)版本內(nèi)容融合。如果分支版本完全需要采用新的實(shí)現(xiàn)，平臺(tái)提供了完整的替換機(jī)制，同時(shí)可選擇是否校驗(yàn)接口的兼容性。

witrix中meta的思想與一般人的第一感覺還是有著本質(zhì)區(qū)別的。在witrix中，典型的開發(fā)過程是通過powerdesigner設(shè)計(jì)數(shù)據(jù)模型，然后自動(dòng)生成meta數(shù)據(jù)，此時(shí)對(duì)于數(shù)據(jù)庫(kù)的增刪改查就可以進(jìn)行了，包括對(duì)于one-to-one,one-to-many,many-to-many等關(guān)系的維護(hù)，高級(jí)查詢條件的拼裝，導(dǎo)入導(dǎo)出功能等。這些設(shè)計(jì)因?yàn)榛贠RM模型，因此并不是僅僅針對(duì)單表的，而是可以很方便的處理關(guān)聯(lián)表的情況。
如果界面沒有特殊要求，一般最多調(diào)整一下meta中字段的屬性。如果完全要求定制布局，則在前臺(tái)通過<df:Field name="fieldName"/>等標(biāo)簽引入字段元數(shù)據(jù)，增刪改界面可以共用一個(gè)定制頁(yè)面。而后臺(tái)依據(jù)meta對(duì)前臺(tái)提交數(shù)據(jù)進(jìn)行初步處理。在witrix的開發(fā)過程中，幾乎不需要調(diào)用get/set方法，也不需要調(diào)用session.save, session.update等方法，前臺(tái)也幾乎不編制完整的界面。

to mixlee: 我們目前無意成為平臺(tái)軟件供應(yīng)商，因此不對(duì)外提供witrix的資料。

Workflow中需要頁(yè)面和流程配合的部分在Witrix中主要通過前臺(tái)js選擇實(shí)現(xiàn)，流程引擎實(shí)現(xiàn)的是事件響應(yīng)而不是驅(qū)動(dòng)界面。 這里倒不太用得上我所謂的PageFlow。 實(shí)際上我是反對(duì)基于action的flow設(shè)計(jì)的。

我所寫的一般都是理論分析,并不是針對(duì)初學(xué)者的介紹性內(nèi)容.
AOP是一種很少限制的結(jié)構(gòu)操縱技術(shù), 你可以去想象它的應(yīng)用

數(shù)據(jù)到底是保存在session中還是request中，對(duì)于這個(gè)問題，基本上它的答案就是應(yīng)該保存在哪里就保存到哪里。 對(duì)于一般簡(jiǎn)單的網(wǎng)頁(yè)，應(yīng)該少在session中存放變量，而對(duì)于復(fù)雜的企業(yè)應(yīng)用，在session中保持狀態(tài)是必要的，不過查出的數(shù)據(jù)一般放在request中就可以了。

一種flow關(guān)注的重點(diǎn)當(dāng)然是協(xié)調(diào)某種類型實(shí)體之間的動(dòng)態(tài)關(guān)系，這其中必然需要一種機(jī)制來保持狀態(tài)信息。PageFlow肯定需要一種大于request而小于session的狀態(tài)保持機(jī)制. Jsplet框架就提供了這種機(jī)制，而PageFlow是運(yùn)行在其上的一個(gè)引擎。

嗯，我們對(duì)hiberante作了一些擴(kuò)展，包括支持公式字段，附件上傳字段等

使用hibernate不是為了從面向?qū)ο蟮挠^點(diǎn)思考設(shè)計(jì)系統(tǒng)這種純學(xué)術(shù)性的目的，而是為了更快更好的解決我們所需要面對(duì)的問題。 witrix平臺(tái)中對(duì)于hibernate的使用是相當(dāng)深入的，包括對(duì)于hibernate的多處hack.
我們需要模型是因?yàn)槲覀冃枰环N控制力， 不在于是否native. 從物理模型恢復(fù)邏輯模型比較直接，并不復(fù)雜， 而且我們并不試圖恢復(fù)整個(gè)邏輯模型，而是得到我們所需要的信息即可。
面向?qū)ο笫鞘裁矗?首先它是一種相關(guān)性的聚集。

@OneEyeWolf
如果你有興趣, 應(yīng)該讀一讀我其他的文章, 以搞清楚我在說些什么.
http://canonical.blogdriver.com/canonical/961298.html

operator的設(shè)計(jì)正在于它的可擴(kuò)展性不夠.

設(shè)計(jì)的實(shí)現(xiàn)方式是設(shè)計(jì)的內(nèi)容之一

@OneEyeWolf
具體實(shí)現(xiàn)的策略就是 CRUD + Filter, 我已經(jīng)寫得非常清楚.

我們的bizflow實(shí)現(xiàn)是基于tpl技術(shù)的，而不是使用operator的概念， 那樣太受局限了。

bizflow是由biz object 驅(qū)動(dòng)的流轉(zhuǎn)，而不是由步驟的先后順序驅(qū)動(dòng)的流轉(zhuǎn)，所以它不是完整的工作流。

簡(jiǎn)單的bizflow可以滿足眾多不需要分支的流轉(zhuǎn)需求，這已經(jīng)足夠做一些有意義的事情。

對(duì)于事件機(jī)制不是設(shè)計(jì)而是描述。

行為之間的順序也是結(jié)構(gòu), 結(jié)構(gòu)這個(gè)詞的含義是非常寬泛的, 我所指的并不是數(shù)據(jù)之間的關(guān)聯(lián),而是泛指關(guān)聯(lián)及關(guān)聯(lián)的集合.

雖然我說過很多遍,但我相信大多數(shù)人仍然沒有明白我所指的在復(fù)雜性級(jí)列之間過渡的含義. 正如我常說的, 一個(gè)人只理解他已經(jīng)理解的東西

沒有這樣的計(jì)劃

架構(gòu)師之家是什么. blog帳號(hào) canonical

jsp tag最核心的設(shè)計(jì)問題在于它所假設(shè)的模型是動(dòng)態(tài)io處理，而缺乏對(duì)于xml結(jié)構(gòu)的充分利用。對(duì)于具體的表現(xiàn)， 我已經(jīng)在一篇blog中作了評(píng)述。
http://canonical.blogdriver.com/canonical/572201.html

應(yīng)該是走高而不是走低。集成的需求促使復(fù)雜性上升。