?

購買鏈接：http://www.china-pub.com/197209

?

?譯者序

?

做.NET 或是微軟平臺的架構設計既簡單又困難。說簡單的理由是，微軟提供的產品往往考慮全面，容易上手，并且文檔豐富。說困難的理由是，微軟往往沒有什么權威性的“指南”推薦說A方面可以用X 技術，B 方面可以用Y 技術（比如JAVA 開發流行的Struts2+Spring+Hibernate 框架），甚至更大的問題是（特別是前幾年）微軟沒有提供針對一些常見技術（比如ORM/MVC/AOP）的“官方”實現。這就使得.NET 平臺的一些系統的架構五花八門，有的架構師愿意自己寫一些輕量級的實現，有的則愿意使用從JAVA 移植過來的一些實現，比如NHibernate、Spring.NET 等。
而現在，《微軟應用架構指南》這本書針對前面提到的問題提供了一個不錯的答案，它針對不同的技術點或應用場景或應用程序的類型，給出了一些微軟平臺（甚至開源界）可用的或是推薦的一些技術或框架，還介紹了何時適用這些技術和框架及在處理這些點的時候應該考慮的問題。更重要的是，微軟在近幾年確實針對很多技術提供了微軟自己的實現，比如ORM 框架ADO.NET EntityFramework、SOA 框架WCF、MVC 框架ASP.NET MVC，等等。對于那些對框架的選擇頭疼（想引入非官方框架卻又怕遇到難以解決的問題）的技術人員和架構師來說確實是好消息。
在翻譯和閱讀本書的過程中，譯者有幾點體會和讀者一起分享。
（一）如何使用本書？
作者不止一次提到本書是一個大綱而不是大全，本書的重點在于介紹架構設計的方法學；架構設計中要考慮哪些方面的問題，這些問題有哪些技術可以解決或實現；微軟平臺有哪些應用程序類型，這些應用程序有哪些技術可以實現；應用程序怎么進行拆分，拆分后的每一部分可以由哪些技術來實現。也就是說本書主要解釋的是有哪些“東西”以及這些“東西”可以由什么來實現這兩個問題。對于后者，由于篇幅的關系只能列出技術或方法的名字然后提供一個參考鏈接。
我們知道，對于架構設計來說，其中包含的技術、框架、原則不太可能靠幾小時或幾天來徹底了解透徹，應該通過閱讀本書來了解我們手里有哪些“東西”，這些“東西”適合什么樣的應用場景。如果在之后架構設計的過程中你發現可以并且適用這個技術，可以進一步深入閱讀和研究這些擴展資料。個人認為應該這樣閱讀本書：首先把自己不知道的知識點通讀補全，然后可以把本書當作一本參考書，在實際架構設計的過程中根據自己的記憶能回憶起“這個問題好像在書中提到過可以用XXX 來解決”，那么再拿起本書找一些書中列出的參考鏈接或在網上找一些參考資料進一步學習。
（二）讀不懂怎么辦？
譯者認為本書針對的是架構師和有架構經驗的開發人員，如果讀者剛接觸程序開發或從未對完整的系統或是系統的一個模塊進行過架構設計（所謂架構設計可以理解為設計一個系統中需要哪些組件及各個組件之間如何協同工作，以及確保這個系統達到預計的質量和需求需要做的工作），那么確實會比較難理解本書，在經過了自己的實踐嘗試之后回頭再閱讀本書您會發現不再是完全看不懂了，而是可以知道自己要了解的那部分內容可以在哪里找到答案。其實，即使是經驗豐富的開發人員和架構師也可能會遇到不理解的內容，因為微軟平臺的技術是如此廣泛，我們的工作往往關注的是某個平臺的開發，比如桌面應用程序、移動應用程序、網站等，而不會面面俱到，因此您完全可以不必介意讀不懂哪部分內容，有的只需要了解即可。
對于每一個方面，本書會列出許多需要考慮的要點，需要實現的步驟，能使用的技術。列出的這些條目源自許多技術專家在針對這方面進行架構設計時積累的經驗，如果讀者進行過這樣的考慮甚至是嘗試，就會容易理解作者想表達的意思，甚至會在讀到這個條目后暗自叫好。譯者就有這樣的體會，由于自己做過一些橫切關注點的框架實現，在閱讀橫切關注點一章時，看到和自己的思考吻合的一些條目時，才能體會到小小的一行條目包含了作者大量嘗試后的經驗和體會（十幾個字歸納了譯者經過幾小時甚至幾天的實踐得出的結論）。相反，對于一些自己不熟悉的技術，確實也難以徹底理解每一個條目。因此，如果讀者正在從事相關架構設計或開發的話，可以再仔細閱讀每一部分內容下的一些子條目，或許你可以有新的發現。
（三）如何進行架構設計？
如何進行架構設計是本書討論的重點，譯者認為最主要的是權衡、漸進兩點。所謂權衡，就是我們在進行架構設計的時候首先需要找出我們的目標包括哪些因素，每一個因素又需要達到怎么樣的指標；然后根據這些因素的重要程度結合我們實際情況（軟硬件、成本、資源）等等權衡得出一種比較適合的架構。所謂漸進就是架構設計和軟件開發相似，應該是一個迭代的過程，每一個系統都會經歷從少到多，從簡單到復雜的過程，我們的架構往往只需要滿足當前的負載即可，過于超前的考慮會帶來不必要的成本，隨著時間的推移，我們可以通過不斷演化架構來滿足新的功能和負載需求。其次，在為一個大型系統做架構設計的時候，可以先考慮把這個架構劃分成獨立的關注點，然后針對每一個點，分別進行方案制定、技術評估、開發測試等過程，最后把每一個點的方案合并在一起組成一個完整的架構。另外，對于架構設計中引入的技術根據項目的性質可以采用不同的策略，如果是一個內部項目，面向少量用戶并且不會是一個長期的項目，那么可以考慮引入一些新技術、新框架，如果是一個外部項目，面向大量的訪問并且需要保持數年的穩定，那么一定要慎用一些未經驗證的新技術，慎用一些我們不能掌控的框架，否則一旦出現問題我們很難在短時間解決。
本書的前半部分（從第1 章開始到第19 章）由我翻譯，后半部分（從第20 章開始到最后）由我的同事高翔翻譯。由于時間和能力的關系，翻譯中肯定有很多不足，歡迎大家提出自己的意見和建議。同樣歡迎讀者和我探討有關架構和設計的問題，我的郵箱是yzhu@live.com。
朱曄
2010年10月

轉載于:https://www.cnblogs.com/lovecindywang/archive/2010/12/03/1895517.html

總結

以上是生活随笔為你收集整理的微软应用架构指南(第2版)出版的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。