這篇差不多算是進入正題了，呵呵。這篇文章主要是實驗性質的文章，大概在一個系列都發完以后我會重新將寫過的東西修改并統稿，按照我一開始希望的樣子把專題組織出來。

該篇將詳細的分析討論ArcGIS Server的Map控件及其Datasource和map functionality的關系問題。
唉。到實際寫文檔的時候，都不知道從哪里下手好，這才覺得Getting Started真不好寫啊。。。

由于個人能力時間有限，如果有錯誤或者不足，歡迎大家批評指正，我將在確認更正后及時的補充修正。

本文將分為兩個部分，第一部分將展現ArcGIS Server的Web ADF架構；
第二部分則使用一個具體的實例來說明Web ADF各個組件之間如何協同工作的。實例來自于Flyinggis的博客，漫游Graphics Data Source。

題外話，此人是高手哇，他的代碼做示例代碼比我自己寫的好多了。他覺得一般的讀者認為理論分析很枯燥，而實踐比較有趣，于是他的系列里面就第一篇是架構性的話題，還有兩個都是實例。但是實際工作中我發現如果要想架構好一個Server，那怕是最簡單的Map Server，光有實踐指導還是不夠的，再加上我一開始就覺得ArcGIS Server的幫助很不完整，這會給框架的理解帶來困難，進而帶來實踐上的障礙，所以我的系列還是側重于框架分析吧。

ps，最近工作比較忙，因此很難一氣呵成，但是我盡力每天寫一點，給大家帶來的不便之處望能海涵。謝謝。

--------------------------------華麗的分割線-----------------------------------------

Part 1 架構分析

引文
在閱讀本文前，我想你已經大致的瀏覽過ESRI ArcGIS Server的文檔：What Is Web ADF？
在該文檔中，ESRI已經將Web ADF的大致框架闡明了。但是在實際工作中，這些內容還不夠。
這一部分將致力于詳細解釋Web ADF的設計，并將Web ADF的概念與.net中的組件結合起來進行分析。
閱讀這一部分不一定需要你讀過What is web ADF，文中會在需要的地方簡要的復述文檔中的內容，并用綠色字體表示，因為本文也可以作為What is Web ADF的導讀。

正文
Web ADF是ESRI為了簡化在Web上提供如地圖瀏覽這樣的GIS服務而實現的一個開發框架。它與其它的相關組件的關系如下圖所示。

從圖中可以看出，Web ADF建立在ArcGIS其它的遠程服務基礎之上，它相當于為各種不同的數據源提供了一個Facade，也可以看作是提供了更高階的抽象層次，成功的將各種不同數據源的訪問統一起來。

下圖為Web ADF的架構圖的簡圖。我們將用這張圖來分析，Web ADF究竟能做什么，它的每個組件分別完成了什么工作，以及這些組件之間是如何協同工作的。


由于這個圖是簡圖，因此也別指望它能反映太多的內涵，但是它所表明的架構還是比較清晰的。圖中組件之間的連線一般來說都是Association或者Aggregation/Composition。
為什么會有這樣的架構？我想這是很多人接觸了ADF以后的疑問。只要分析清楚了架構為什么會演化成這樣，那么實際的軟件如何利用這個架構的問題自然也就解決了。
我們先來看看Web ADF的官方文檔是怎樣描述這個框架的。
從整體上說，Web ADF提供了多數據源的地圖顯示、簡單的空間分析功能，以及針對特定數據源的特定功能。注意我這里的描述，無論是地圖顯示，還是空間分析，抑或是地址編碼和地處理，他們都可以看作是一個“功能”。
注：如果是指ArcGIS Server中的術語“功能(Functionality)”，一律使用“Functionality(-ies)”，如果是指通常含義上的功能，則使用中文的“功能”，下同。
也就是說，我可以將ADF所面臨的需求：Web地理服務用各種“功能”進行劃分。
可能是出自于這種考慮，ESRI將Web ADF的用戶交互部分框架以“功能”為核心進行考慮并通盤規劃，即Functionalities。
例如，地圖渲染，依賴于Map“功能”，也就是MapFunctionality；而地址編碼，依賴于GeocodeFunctionality，等等。
而Control，則是負責具體數據的渲染與顯示，以及處理用戶交互。那么很明顯的，在圖中，Control和Functionality構成了一個兩層關系：Control負責表現層的工作，而Functionality則負責處理邏輯。
具體到MapControl和MapFunctionality上，MapControl只負責數據顯示以及用戶操作的接收，而MapFunctionality則具體負責地圖的渲染工作。
綜上所述，每個Functionality都代表了實際中人們需要的一些相關功能的集合。

僅有功能自然是不行的，還要有相關的數據。在這里我們注意到一點，那就是數據源經常決定了有那些功能可以實現，有哪些功能不可以。例如，如果數據源是一個沒有幾何信息的數據集，那么地圖繪制也就無從談起。
因此可以說，功能能否實現，將取決于數據的情況，這也就是為什么會有Resource與Functionalities之間會有短線。
由于是資源決定能夠實現的功能，而反過來就不成立了，因此在Object Model Diagram中，可以看到Resource與它的Functionality是Instansation的關系，也就是說，一個Functionality是由一個唯一的Resource所構造出的（也就是實例化出），而一個Resource，可以依據其情況，構造多個Functionality，例如對于Geodatabase中的Feature Class而言，它既能夠用其渲染，也能夠用于查詢操作，那么很顯然，它便可以構造MapFunctionality和QueryFunctionality，而對于GraphicsLayer這樣的數據源，則無法完成查詢工作，因此它也就無法創建QueryFunctionality。下圖表示了Functionality和Resource之間的關系。


很自然的，Control - Functionality - Resource構成了一個微型的Presentation - Logic - Data的三層架構。

（待續）