tag:blogger.com,1999:blog-4500363753981919783.post3392504201398050460..comments2023-10-03T22:06:50.708+08:00Comments on Huan-Lin 學習筆記: 應用程式的分層設計 (3) - DDD、六角、與洋蔥架構Michael Tsaihttp://www.blogger.com/profile/00364693770445538641noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-4500363753981919783.post-22808576620003597802012-10-09T13:47:25.764+08:002012-10-09T13:47:25.764+08:00的確,剛開始使用 DI 時,不應急著用 IoC container 解決一切問題,而應優先考慮其他 ...的確,剛開始使用 DI 時,不應急著用 IoC container 解決一切問題,而應優先考慮其他 DI 技巧或設計模式,例如建構式注入或工廠模式。否則很可能因為誤用而成了 anti-pattern 的實踐者。為了避免誤導,我對於文中提到 IoC container 的部分也稍微加了點潤飾。<br />Thanks!Michael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-61448762930439550112012-10-09T12:46:19.643+08:002012-10-09T12:46:19.643+08:00itplayer 和 Clark 真是太客氣啦!
我只是做點文字整理和打字的粗淺工夫,主要是花時間而...itplayer 和 Clark 真是太客氣啦!<br />我只是做點文字整理和打字的粗淺工夫,主要是花時間而已。不過,能再看到兩位專家出手分享實戰的寶貴經驗,值得! 多謝多謝 ^^<br />Michael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-84814331915554636622012-10-09T11:42:50.064+08:002012-10-09T11:42:50.064+08:00IoC 我覺得不用太快引入,先利用 Factory 的做法來進行雛形的設計規劃。等到有二次需求的時候...IoC 我覺得不用太快引入,先利用 Factory 的做法來進行雛形的設計規劃。等到有二次需求的時候,確認變動點,再來進行 IoC 的引入,比較可以看到效用。<br /><br />過早引入 IoC 增加開發風險(風險來自於學習成本,以現在的大環境來看,junior developer 都不具備這種能力,一時半刻要訓練起來,頗為辛苦)當然,架構師如 Clark 這種等級的,一開始規畫得宜,又另當別論。 :D <br /><br />這些系列文章也是我當年入門大型系統架構時候,掙扎多年所過濾下來的好文,在經歷過多年的實作後,更覺得此架構的平衡。<br /><br />huanlin 兄點出了洋蔥架構的相依問題,但是對於生命週期長的大型企業應用系統,或是產品,相依的犧牲,以個人的淺見,是相對划算的。<br /><br />追求無(超低)相依完全隔離的代價很高,最起碼,老闆一定得幫該架構師保險。 :D<br /><br />尤其現代講求 SOA 的作法,洋蔥或是六角架構所能體現的價值,更佳能表現出來喔。<br /><br />再次謝謝 huanlin 兄的撰文推廣,以及 Clark 精闢的實戰經驗分享。itplayernoreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-48868509862044045202012-10-09T11:02:22.959+08:002012-10-09T11:02:22.959+08:00反覆讀了這篇文章,真的是淺顯易懂。
受教了~ ^^反覆讀了這篇文章,真的是淺顯易懂。<br />受教了~ ^^Clarkhttp://www.dotblogs.com.tw/clark/noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-83034681974506534572012-10-09T10:49:06.905+08:002012-10-09T10:49:06.905+08:00=====關於抽掉基礎建設=====
1. 系統使用基礎建設,引用的方式通常會是使用靜態參考或是直...=====關於抽掉基礎建設=====<br /><br />1. 系統使用基礎建設,引用的方式通常會是使用靜態參考或是直接建立。<br />2. 而物件導向中要抽離某個相依,最常使用的就是套用一層IoC,讓系統改相依介面而不依賴實做。<br />結合這兩個概念不難總結出,只要套用IoC就可以抽離基礎建設。<br /><br />但實際實做上會遇到的困難是,<br />採用IoC來隔離基礎建設實做,必須要將實做傳遞到每個使用基礎建設的物件。<br />這點會讓整個系統充滿了基礎建設參考的傳遞,光是用想的就覺得頭皮發麻。<br /><br />為了解決這個問題,在專案開發上都使用下列文章的模式,來隔離各種基礎建設。<br />[Architecture Pattern] Inversion of Logging<br />http://www.dotblogs.com.tw/clark/archive/2012/09/02/74538.aspx<br /><br />文章中的模式,也是採用IoC來完成隔離基礎建設的功能。<br />不同的只是改採用一個靜態屬性,<br />作為系統內部取得基礎建設的參考、也做為外部DI注入IoC實做的參考點。<br />(可以把這個靜態屬性,看成簡化版的 Service Locator)<br /><br />透過這樣的方式,使用IoC將基礎建設隔離在系統之外,<br />複雜了一點但是提高不少系統重用實的適用範圍。 :D<br /><br /><br />=====IoC=====<br />最後補充一個IoC的相關資料,其實比想像中簡單很多,不用IoC Container也可以完成。:D<br />[Object-oriented] 控制反轉<br />http://www.dotblogs.com.tw/clark/archive/2010/11/29/19772.aspx<br />Clarkhttp://www.dotblogs.com.tw/clark/noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-74756153935440190762012-10-09T10:40:38.184+08:002012-10-09T10:40:38.184+08:00domain 不依賴任何 layer 的作法,才可以方便未來 domain 的重用(或是實作的更換)...domain 不依賴任何 layer 的作法,才可以方便未來 domain 的重用(或是實作的更換)。例如產品的開發,都希望可以 design 出一個 general 的 model, 如果這個 model 成功,可預期的是這個產品生命週期會超過五年以上,但是 IT 技術五年已經兩個世代更迭了,這時候不依賴特定 layer 的 domain 也意味著部會依賴到特定技術,五年內就可以用新的實作技術來完成。huanlin 兄實在是非常有心,雖然這個洋蔥架構我用了好多年,但始終也沒有勁去演繹中間這麼多的思考並且為文。非常感謝您又為台灣軟體開發人員開了一扇大窗。 :Ditplayernoreply@blogger.com