Posted on 2010-06-20 23:37
切爾斯基 閱讀(2246)
評(píng)論(2) 編輯 收藏
同一個(gè)Feature的代碼要放在一起(IDE里單獨(dú)的一個(gè)工程, 或者工程里單獨(dú)的一個(gè)文件夾), 這些代碼要么全有要么全無的, 它們合作完成一個(gè)Feature, 如果用戶不再需要這個(gè)Feature了, 可以把它們整個(gè)的痛快的刪掉, 不會(huì)留下誰也用不到的代碼成為系統(tǒng)的垃圾. 如果想看一個(gè)Feature是如何實(shí)現(xiàn)的, 那所有相關(guān)代碼都在一起, 不需要在龐大的代碼庫中跳來跳去.
那么理想的情況就是: 你看看源代碼樹里所有工程文件的名字, 或者文件夾的名字, 就知道系統(tǒng)提供了哪些功能, 它可以跟你的需求描述對(duì)應(yīng)起來, 無論用User Story還是Use Case, 都可以用它們的名字作為工程名或者文件夾的名字, 方便維護(hù)
流行的MVC框架缺省的物理文件組織并不是這樣的, Controller, Model, View分別在不同的文件夾里面. ASP.Net MVC提供了VirtualPathProvider以及ViewEngine, 可以讓我們把一個(gè)Feature的Controller/Model/View統(tǒng)統(tǒng)打包到一個(gè)project或者文件夾而運(yùn)行時(shí)依然能夠找到對(duì)應(yīng)的action和view, 這是我們正在利用的特性
這種代碼組織方式對(duì)架構(gòu)的影響是什么?
這基本會(huì)導(dǎo)致基于插件/擴(kuò)展點(diǎn)的體系結(jié)構(gòu). 放到更大尺度上, 就是SOA. SOA才是王道. 這個(gè)詞太大了, 還是先聚焦到一個(gè)進(jìn)程的應(yīng)用....
1. UI如何聚合? 最終用戶看到的UI, 是一個(gè)聚合的結(jié)果, 可能來自系統(tǒng)的不同部分. 解決這個(gè)問題的擴(kuò)展點(diǎn)技術(shù)有客戶端的Ajax, 或者服務(wù)端的RenderAction. (問題: Css應(yīng)該如何處理? 不同部分的顯示順序, 布局如何確定?)
2. Feature如何溝通? Feature之間不可能一點(diǎn)依賴沒有, 比如可能會(huì)用到相同的數(shù)據(jù), 相同的業(yè)務(wù)邏輯. 解決這個(gè)問題的方法有Bounded Context, Context Mapping, DCI...都是一回事
3. 數(shù)據(jù)庫如何劃分? 不同的Feature使用自己的獨(dú)立定義的數(shù)據(jù)表, 做映射和同步, 也是同樣的方案
4. 如何把這些Feature組裝在一起? Java平臺(tái)有OSGi, .Net目前沒有看到跟OSGi類似的方案. 基本是注冊(cè)或動(dòng)態(tài)發(fā)現(xiàn)的路子, 遵循開閉原則...