Microsoft.Net企業級應用架構設計之最后的思考

jopen 12年前發布 | 27K 次閱讀 架構 軟件架構

前段時間剛剛看完《Microsoft.Net企業級應用架構設計》一書,很值得對想涉入架構方面的童鞋們推薦,具體的內容在接下來我會慢慢的總結和分享。首先我分享本書最后的作者總結。希望用作者的總結作為我寫架構方面文章的一個引子。

最后的思考

箴言1--凡事無絕對

凡事無絕對。作為架構師,你永遠不會對任何事有百分之百的把握,你永遠無法面面俱到。不過在這個位置上,你必須評估所有的可選方案,并做出有足夠預見性的正確決策。你需為自己爭取一些時間,以便慢慢思考,因此首先說"凡事無絕對“,然后解釋為什么是這樣,變數有哪些。若你還不確定有哪些變數,那么可以選用這個通用的回答----“這取決于上下文”。

箴言2--需求是超越一切存在的

架構僅僅是軟件 項目中一個自的鏈接部分。客戶將說出他們需要什么,若是客戶不清楚自的需,那么會有人引導直至得明確的答案,這是分析師的職責。項目經理將為這個已經正式確定的項目安排基礎設施。架構師會得到所有的需求,并為開發者提供設計。開發者將按照架構的意圖開發。數據庫管理員也會盡力讓數據庫能良好支持應用程序。你會認識到,客戶位于這個鏈條的頂端,且客戶的需求才是最重要的部分,客戶所需要的東西叫做需求。當然,沒有幾個客戶知道他自己真正需要的是什么,因此需求會不停地變化。

箴言3--根據接口編程

雖然我們是依靠最終實現代碼來完成需求的,不過仍應該盡可能地使用接口。請牢記“沒有接口的話就不要開始實現”這句話。仔細分析,你總會找到可以提取的接口。

箴言4--保持簡單,但不過于簡單

你應該聽說過Kiss(Keep It Simple Stupid)原則,但這只是我們修改后的觀點。簡潔明了通常就意味著優秀。以簡單為目標,不過要留有自己的底線。若是低于這個底線,那你的解決方案將變得過于簡單,這并不是一件好事。

箴言5--繼承是為了多態,不是重用

面向對象編程讓我們僅編寫一個類,然后不停地重用并根據需要擴展,這是依靠繼承實現的。不過這就是類重用的全部嗎?“重用”這個概念要比你延續一眼看上去更加微妙。多態是面向對象編程的核心功能,意味著你可以互換地使用兩個繼承類。同時,有些人給出了總結:“重用是繼承的一個附帶功能。”不過重用不應該成為你的根本目標,換句話說,不要僅為了重用而使用繼承。最好是編寫一個新的類來滿足需求,而不是繼承某個原本不是完此工作的現有類。

箴言6---不要在非數據訪問層中使用SQL

牢記這一條:分離關注點。將數據訪問代碼和細節(例如,連接字符呂、命令和數據表名)先放在一邊。或早或晚你總會開始處理,不過不是在設計業務邏輯層和表現層時。如果可能,請將持久化工作交給對象/關系映射(object/Relation Mapper)等專門的工具處理。

箴言7--首先考慮可維護性

若你僅能為軟件選擇一個特性,那么應該如何選擇呢?選擇可伸縮性、安全性、性能、可測試性還是可用性呢?在我們看來,上述這些都不是最重要的,最重要的是可維護性。有了可維護性,上述所有的特性都可以在日后實現。

箴言8---所有的用戶輸入都是罪惡的

你應該早已聽說過這種說法。“紙包不住火”,若是有某種途徑讓用戶可以入侵,那么遲早會被用戶發現。這似乎是墨菲法則,確實如此。

箴言9---事后優化

Donald Knuth曾說過,過早地優化是所有軟件 罪惡的根源。我們將該說法更進一步說-----不要優化系統,而是讓其設計盡可能地靈活面對改進和擴展,僅在系統完成之后,再關注純粹的優化。

箴言10----在設計時就考慮安全性和可測試性

若你很在乎某個系統特性,那么在設計開始前就應考慮到它。安全性和可測性也是如此,甚至一個國際標準化組織(ISO)的規范也明確地闡述了這一點。

轉自:http://blog.csdn.net/fengyarongaa/article/details/7943947

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!