ArcGIS SERVER JAVA为什么选择JSF

在正式开讲之前，我们来探讨一下为什么要使用JSF来实现SERVER ADF，这也是很多开发商跟我讨论时经常会问到的问题。

      世界上有300种Java的framework，这个数字是我几个月前听到的，现在可能已经不止这个数了。我曾经用过的framework包括Structs，Hibernate，Spring。这些framework不但能加速开发，而且会带来全新的程序设计理念。我当时的感觉是：原来程序还可以这样写！ 当然，这些framework都是开源免费，你不用担心自己的良心受到谴责，也不用担心比尔盖茨半夜敲门收钱。

       在这300多种framework中，ESRI为什么选择了JSF？各个framework有各个framework的好处。JSF最大的优点就是：像 Swing 和 AWT 一样，JSF 是一个可以提供一组标准的、可重用的 GUI 组件的开发框架。

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

     行为和表现不分离的一个典型例子是普通的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，可以更加容易编程和实现。

    这是ESRI选择JSF的重要原因之一。<转>