循證架構--尋找最适合自己的架構

沒有最好的架構，隻有最合适的架構。循證架構是《Expert One-on-One J2EE Development without EJB》一書中推崇的架構思路，用俺們的話說就是摸着石頭過河，找最适合自己的架構。

俺現在soho，大活不多，小活不斷。我的工作具備以下特點：

（1） 根本沒摸清楚需求的時間。需求都是從原型到Demo到版本1到版本2探索出來的。經常需求變化非常大，是以，必須以靈活方法為基礎；

（2） 一般沒多少資料需要存儲，頂多百萬級；

（3） 需要極度的壓榨開發效率。一個工作，10天完成和20天完成，那收益前者就是後者的兩倍。

在上面（1）-（3）驅動下，俺摸索出的架構見下圖：

<a href="http://images.cnblogs.com/cnblogs_com/xiaotie/WindowsLiveWriter/33b8fa778f3e_52CF/myarch_2.png"></a>

從下往上，簡單說說：

（1） 資料庫：db4o。誰用誰知道，哈哈，爽。什麼ORM，SQL，DataSet，統統是過眼雲煙了。一切都是普通對象。資料庫幾乎是0設計。資料接入也非常非常的簡單。

（2） Db4o之上得有一個邏輯層，來應付需求變化。這一層主要就是各種實體對象，需要良好的設計，否則，應付不了需求的變化。這一塊我一般要設計比較完備的event體系，便于後期修改與組合。

（3） 服務層：主要是RIA應用需要。如果是Winform程式，不用這一層。

（4） UI邏輯層：最開始沒弄這一層，最後鑒于在界面那一塊太耗時間，就加了這麼一層。這一層主要是：

a) 對于單個控件，将控件的常用操作邏輯封裝成擴充方法；

例子： Winform程式中的Invoke方法使用起來很煩人，涉及到多個線程，還要判斷多次 IsHandleCreated == true（經常忘記，導緻bug）。于是，需要将它封裝成擴充方法。

代碼如下：

Code

b) 對于多個控件，使用Mediator模式，将多個控件之間的組合抽象出Mediator類，友善重用。這一點我最開始是使用者控件方式進行封裝，結果發現太不靈活，最後改用Mediator，再配合擴充方法，開發速度biubiubiu的就上去了。

（5） UI：Html是萬惡之源，能不用就不用。可以選擇的話，我主要用Winform, Flex，SL作為前端。純Web開發是不碰了（市面上做Web開發的太多，不趟這個混水了）。

以上架構，視項目而定。如果項目的資料部分比較關鍵，我現在還是保守的在用關系資料庫。雖然db4o已經那麼多年了，還是得保守一點用。

如果能完全按上面五點去做，那開發簡直和在空中飛翔一樣爽。

btw. 如果一切都OO起來，寫程式真是享受，象寫詩一樣……

本文轉自xiaotie部落格園部落格，原文連結http://www.cnblogs.com/xiaotie/archive/2009/05/21/1485795.html如需轉載請自行聯系原作者

xiaotie 集異璧實驗室(GEBLAB)