ArcGIS Server 9.2 专题 试验田(1) ArcGIS Server Map Control及相关组件解读
这篇差不多算是进入正题了，呵呵。这篇文章主要是实验性质的文章，大概在一个系列都发完以后我会重新将写过的东西修改并统稿，按照我一开始希望的样子把专题组织出来。
该篇将详细的分析讨论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与相关组件关系
从图中可以看出，Web ADF建立在ArcGIS其它的远程服务基础之上，它相当于为各种不同的数据源提供了一个Facade，也可以看作是提供了更高阶的抽象层次，成功的将各种不同数据源的访问统一起来。
下图为Web ADF的架构图的简图。我们将用这张图来分析，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之间的关系。
DataSource - Resource - Functionality 关系图
很自然的， Control - Functionality - Resource构成了一个微型的Presentation - Logic - Data的三层架构。
（待续）
该篇将详细的分析讨论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与相关组件关系
下图为Web ADF的架构图的简图。我们将用这张图来分析，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之间的关系。
DataSource - Resource - Functionality 关系图
很自然的， Control - Functionality - Resource构成了一个微型的Presentation - Logic - Data的三层架构。
（待续）