淺析.NET設計架構十條箴言

箴言一——凡事無絕對

凡事無絕對。做爲架構師，你永遠不會對任何事情有百分百的把握，你永遠沒法面面俱到。不過在這個位置上，你就必須評估全部的可選方案，並做出有足夠預見性的正確決策。你須要爲本身爭取一些時間，以便慢慢思考，所以首先說「凡事無絕對」，而後解釋爲何是這樣，變數有哪些。若你還不肯定有些變數，那麼能夠選用這個通用的回答——「這取決於上下文」。

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

架構僅僅是軟件項目中一個天然的連接部分。客戶將說出他們須要什麼，如果客戶吧清楚本身的需求，那麼會有人引導直至獲得明確的答案，這是分析師的職責。項目經理將爲這個已經正式肯定的項目安排基礎設施。架構師會獲得全部的需求，併爲開發者提供設計。開發者將按照架構的意圖開發。數據庫管理員也會盡力讓數據庫能良好支持應用程序。你會認識到，客戶位於這個鏈條的頂端，且客戶的需求才是最重要的部分，客戶所須要的東西叫作需求。固然，沒有幾個客戶知道他本身真正須要的是什麼，所以需求會不停地變化。

箴言3——根據接口編程

雖然咱們是依靠最終實現代碼來完成需求的，不過仍應該儘量地使用接口。請牢記「沒有接口的話就不要開始實現」這句話。仔細分析，你總會找到能夠提取的接口。

箴言4——保持簡單，但不過與簡單

你應該據說過KISS（Keep It Simple，Stupid）原則，但這只是咱們修改後的觀點。簡潔明瞭一般就意味着優秀。以簡單爲目標，不過要留有本身的底線。如果低於這個底線，那麼你的解決方案將變得過於簡單，這並非一件好事。

箴言5——繼承是爲了多態，不是重用

面向對象編程（OOP）讓咱們僅編寫一個類，而後不停地重用並根據須要擴展，這是依靠繼承實現的。不過這就是類重用的所有嗎？「重用」這個概念要比你第一眼看上去更加微妙。多態是面向對象編程的核心功能，意味着你能夠互換地使用兩個繼承類。同時，有些人給出了總結：「蟲咬是繼承的一個附帶功能。」不太重用不該該成爲你的根本目標，換句話說，不要僅爲了重用而使用繼承。最好是編寫一個新的類來知足需iqu，而不是繼承某個本來不是完成此工做的現有類。

箴言6——不要再非數據訪問層中使用SQL

牢記這一條：分離關注點。將數據訪問代碼和細節（例如，鏈接字符串、命令和數據表名）先放在一邊。或早或晚你總會開始處理，不過不是在設計業務邏輯層和表現層時。若是可能請將持久化工做交給對象/關係映射（Object/Relational Mapper）等專門的工具處理。

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

若你僅能爲軟件選擇一個特性，那麼應該如何選擇呢？選擇可伸縮性、安全性、性能，可測試性仍是可用性？在咱們看來，上述這些都不是最重要的，最重要的是可維護性。有了可維護性，上述全部特性均可以在往後實現。

箴言8——全部的用戶輸入都是罪惡的

你應該早已聽過這種說法。「紙包不知火」，如果有某種途徑讓用戶能夠入侵，那麼早晚會被用戶發現。這彷佛是墨菲法則，確實如此。

箴言9——過後優化

Donald Knuth曾說過，過早地優化時全部軟件罪惡的根源。咱們講該說法更進一步——不要優化系統，而是讓其設計儘量地面對改進和擴展，僅在系統完成以後，再關注純粹的優化。

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

若你很在意某個系統特性，那麼在設計開始前就應該考慮到它。安全性和可測試性也是如此。甚至一個國際標準化組織（ISO）的規範也明確地闡述了這一點。