頭疼的Bug，糟糕的代碼，崩潰的調試作為開發人員的你，遇到上述任何一種情況可能就會陷入抓狂。如果能直接獲得需要的代碼，編程的活兒就會輕松許多。

　　微軟最新推出的一站式示例代碼庫，讓開發人員可以免費獲得所需的示例代碼或向微軟工程師提出示例請求，輕松解決常見的編程問題，大大減輕工作負擔。

　　本文以一個名為AzureBingMaps的示例應用程序為例，分享了一些在開發該示例過程中積累的經驗，以期對廣大開發人員有所幫助。AzureBingMaps是一個旅游站點管理系統，演示了很多技術，可以認為是一個實際項目。

　　寫這個示例的初衷

　　在Windows Azure論壇，我們常見到這樣的開發人員：他們已經學習了很多開發技術，例如ASP、.NET、Silverlight等，并對這些技術有了較深入的了解。但當他們需要將學到的知識應用到實際項目中時，新的問題便產生了。

• 針對特定場景該如何選擇平臺和技術？

• 不同的技術怎樣結合起來使用？

• 如果在使用某項技術的過程中發現了局限性該如何解決？

• 如果必須使用不熟悉的技術該怎么辦？

　　如今的網絡技術資源絕大多數都只針對某一種特定的技術，指導人們如何使用一個特定的功能，對那些希望學以致用、開發實際項目的開發人員而言，這遠遠不夠。

　　鑒于此，我們開始嘗試使用微軟的各種技術開發一個相對完整的項目，體會大家可能遇上的問題，從而形成了本文。

　　選擇合適的平臺與技術

　　了解用戶需求

　　在項目開發前，必須了解客戶的需求。這項工作的范圍很廣，但由開發人員負責的部分通常僅限于選擇合適的平臺與技術。因此作為一個示例，我們省略了與客戶訪談以了解需求的過程，直接將非功能性需求定義如下。

• 本系統在旅游旺季需要支持1,000,000個用戶同時訪問，在非旅游旺季只需要支持1,000個用戶同時訪問。

• 公司沒有自己的數據中心，IT部門最多只能提供3臺中檔服務器給我們的系統。

• 我們團隊對.NET和Visual Studio比較熟悉。

• 本系統對操作系統及網絡環境并沒有特定的需求。

• 第三方開發人員應該可以針對我們的服務自行開發客戶端應用程序。

　　這些需求也正是我們的客戶—Windows Azure論壇上參與討論的開發人員—常常需要解決的問題。

　　選擇合適的平臺

　　需求明確地指出可伸縮性是必須考慮的因素。為了滿足旅游旺季時1,000,000個用戶同時訪問的需求，我們可能會考慮如下方案。

• 使用一臺高性能服務器，然而IT部門明確告訴我們他們只能提供3臺中檔服務器。

• 采用負載平衡，然而3臺中檔服務器即使采用了負載平衡也很難保證滿足我們的需求。

• 尋找云計算供應商，將我們的系統部署在外部的數據中心，如果選擇的供應商合適，支持多臺服務器負載平衡，就能確保滿足高并發訪問的需求。

　　于是，我們的需求引領我們考慮選擇云計算。然而市場上也有很多云計算供應商，選擇哪家最適合呢？這個問題還是要通過需求來解答。

• 在非旅游旺季我們只需要支持1,000個用戶同時訪問，因此我們選擇的供應商必須允許我們隨時更改使用計劃，例如，旅游旺季租用2,000臺服務器，非旅游旺季只租用2臺服務器。

• 鑒于項目組對.NET和Visual Studio比較熟悉，我們希望應用現有的知識進行開發，這意味著我們選擇的供應商必須支持.NET。

• 既然我們的系統對操作系統和網絡環境沒有特定的需求，我們就不希望花太多的時間在這些環境配置上。例如，我們不希望手工配置操作系統和安裝各種需要的軟件；希望即使需要租用2,000臺服務器，也可以讓項目組致力于應用程序的開發，而不是基礎設施的配置。

　　綜上所述，我們發現Windows Azure平臺可以滿足需求。在Windows Azure平臺中，我們可以隨時簡單通過修改配置文件的方式來選擇租用幾臺服務器，而且理論上可租用的服務器數量確實沒有上限。它也完全支持.NET平臺，而且操作系統以及常用的軟件（例如數據庫），也不需要手工配置。

　　當然，我們承認如上定義正好符合WindowsAzure平臺的需求，這也是出于我們是針對這個平臺撰寫示例的考慮。但在實際項目中，大家確實需要考慮上述因素。如果你不需要高度可伸縮性，Windows Azure平臺可能就不適合你，畢竟它的價格相對于一般的Web供應商而言是比較高的。如果你對操作系統和網絡環境有特定的需求，那么目前Windows Azure平臺也不適合你。你應該根據實際需求，尋找合適的平臺。

　　選擇合適的技術

　　在選取技術的過程中，客戶需求以及開發團隊的經驗也是非常重要的。

　　需求指出第三方開發人員需要針對我們的服務自行開發客戶端程序，因此開發服務時我們需要選擇一個能讓較多客戶端平臺都接受的技術，最好是一個國際標準。于是我們決定使用REST。此外，我們的服務需要暴露一些數據給客戶端，因此將使用OData。OData是基于REST標準，定義了如何訪問數據的一種拓撲，并且被廣泛地使用著。我們的開發團隊熟悉.NET，于是我們選擇在.NET平臺上能方便地實現OData的一項技術，也就是WCF Data Services。

　　在數據存儲方面，Windows Azure平臺上有兩種常見的數據存儲服務：Table Storage和SQL Azure。考慮到Table Storage目前還有較多局限性（例如不支持排序），我們決定使用SQL Azure。不過SQL Azure也有自己的局限性，最重要的一點就是目前它不具備Table Storage所提供的自動伸縮功能，也就是說當數據量大的時候，如何確保高效訪問數據，是一個問題。不過這個問題也不是特別難以解決，請參考本文設計可伸縮的數據庫章節尋找解決方案。此外，SQL Azure還支持空間數據（Spatial Data），也就是存放地理信息的數據，我們示例的場景正需要地理信息，所以空間數據也是一個很自然的選擇。

　　至于數據訪問，.NET平臺提供了Entity Framework，這是一種O/R Mapping的框架，可以讓開發人員在不需要考慮如何撰寫SQL語句的情況下進行數據訪問操作，而將精力專注于面向對象的設計。不過目前Entity Framework對空間數據的支持并不很完美，所以采用它將會給項目帶來一定風險。

　　另外一個選擇是直接使用SqlConnection以及SqlCommand，但這種方式比較煩瑣，而且代碼也不易維護。綜合考慮，我們決定先做一個簡單的原型，嘗試將Entity Framework和Spatial Data結合使用，如果在開發該原型的過程中遇上了太多困難，我們將采用SqlConnection的方式。當然最終證明困難并不是很大，于是我們的示例還是采用了Entity Framework。

　　最后還有客戶端，在客戶端的技術選擇上，我們首先考慮是選擇Web還是Desktop。絕大多數情況下，Web應用程序都占據著得天獨厚的優勢，因為用戶不需要安裝，甚至不需要下載。當然Web應用程序在用戶體驗上可能略有不足，不過隨著HTML5以及Silverlight的普及，差距也是越來越小了。如今Desktop程序最大的優勢在于能夠訪問更多的系統資源，以及可以更好地支持離線使用。

　　對于我們的場景而言，我們不需要訪問特定的系統資源，而且可以暫時不考慮離線訪問的狀況，所以針對PC類的大型設備我們選擇了Web。不過，手機類的設備則是另外一回事。大多數手機瀏覽器不僅相對而言屏幕較小，而且功能支持也比較少，例如Silverlight一類的插件不受支持，而且也缺乏PC瀏覽器常見的那種TabbedView一類的效果。所以如果針對手機設備開發，往往還需要選擇該設備直接支持的技術。

　　至于為何選擇AJAX和Silverlight兩個PC客戶端，以及Windows Phone，就純粹是出于示例的需要了。還是那句話，如果你的需求不同，你就應該根據需求選擇適合于當前項目的技術，而不是生搬硬套...