ArcGIS Server 的体系架构

 

                                            ADF  (Application Developer Framework)

 

为什么要使用JSF来实现SERVER ADF(转载)

原因之一： 行为与表示的完全分离。

     行为和表现不分离的一个典型例子是普通的JSP 技术，这一技术很好，因为很容易在 HTML（和类 HTML）页面中混合 Java 代码。这样我们就可以使用强大的Java API的功能。当然，很明显的坏处是行为表现黏合在一起。而且代码不容易重用。这让我想起刚使用JSP技术时，在文本编辑器下写JSP页面，读写数据库，并且在同一个页面上显示出来的痛苦回忆。
      Model1架构的出现使开发人员可以用javabean的方式进行开发，舒服多了。当然，还有更好的。
      这就不得不提到著名的MVC结构，(MVC) model-view-controller: 模型—视图—控制器模式架构提供了一系列的设计模式，这些模式让你可以轻松地应用于程序地开发，特别是有界面程序的开发。现在又有多少的程序是没有界面的呢？  
      Model包装了商业逻辑，也包含了数据持久的代码，包括存取数据库或者存取文件。Model最好不要跟View有任何关系，它最好不要知道谁将显示结果，是一个Swing界面，还是JSF界面，还是普通的JSP界面。为了做到这一点，事先的规划要花一些时间，但是相信我，这些花的时间带来的价值将超过你的想象。如果设计得当，许多用ArcGIS Engine开发的代码可以轻松在Server中使用，不需要修改任何代码。.net也是一样。
      View只用来显示显示逻辑，不能有任何商务逻辑。controller是view和model的桥梁，它和model进行交互，并且把结果显示在Model中。显示页面的选择也由controller进行选择。我会在后面的讲座中详细解释JSF中的Controller的实现。
       Structs，Spring都实现了MVC的架构。但是它们都没有像JSF这样，提供一个事件驱动的组件对象模型。大家可以想一想，一个平常在HTML中使用的标签，     <input type="text" name="q">，在JSF框架中变成了一个组件，这个组件还可以有事件，而且可以对这个事件可以进行编程。这是多么得激动人心啊！ GIS程序需要和用户进行良好地交互，选择一个事件驱动的framework，可以更加容易编程和实现。

原因之二: 事件容易捆绑到服务器端代码。
JSF提供了多个事件驱动的GUI控件, 比如最最常见的command button。这些command button会产生事件，我们有机会对事件进行编程；我在以前的讲座中曾经讲过，ArcGIS Server的MapControl和command button是兄弟，他们都继承自javax.faces.component.UICommand；是不是感觉很奇妙啊？继承自UICommand的原因是要利用UICommand的很多事件，对鼠标在Map Control上的动作，比如放大，缩小，需要产生事件，这些事件提交到相应的监听器，监听器会对事件进行处理。有关于MapControl的问题先提这些，在后面的讲座中我会详细解释。    
     举一个简单的例子吧，一个最简单不过的fullextent工具，如果我自己来写，可以写成这样：
<h:commandButton id="redisplayCommand" type="submit" value="Full Extent" actionListener="#{getMapBean.getFullMap}" />
这个按钮，用来缩放到全图，它的监听器是绑定到getMapBean的getFullMap方法，在该方法里面，我会将地图的大小缩放到全图范围。代码我会稍后贴上来。这就是JSF的事件捆绑到服务器代码的功能。普通的一个button，点击事件可以映射到后台Bean的某一个方法，在后台方法里面执行商业逻辑，进行数据存取。这个概念跟普通的Swing程序的事件和监听器机制十分类似，Java程序员们看了肯定倍感亲切。注意，刚才这个button没有利用任何ADF的类，在我们的ADF中，所有要建大厦的材料都已经给您准备好，fullExtent功能只需要三行代码即可实现。
事件容易捆绑到服务器端代码，这是ESRI选择JSF作为我们ADF底层的另外一个重要的原因。

转载于:https://www.cnblogs.com/hualirpool/archive/2008/11/15/1334005.html