网络应用程序的框架

     随着技术的发展，网络开发的分工越来越细了，如何进行更加细致的分工是当前提高开发的效率的一个重点之一。因此，j2ee很多框架都努力向更加明确的分工发展，这几年来，MVC框架满天飞，关于框架的技术也不断的发展与成熟，诸如：struts，webwork，spring mvc都是其中的代表，同时由于组件技术的发展，如何更好的的把组件引入商业网站开发中也是一大焦点问题。前一种方式是基于用户的请求和url处理来反馈用户信息，后一种是通过组件的点击并反应的思想来考虑，这两种处理用户请求的思想是当前的两大框架主流。
     让我们回顾一下网络的发展，
      1）html超文本协议可以为客户显示丰富的内容，但是如果就这些单一的网页内容并没有什么意义，这种情况用户并不能与服务器进行交互，并根据个人的信息来处理相应的要求。加上计算机本来就是为用户进行服务的，从这方面来考虑，每一台提供了某些服务的计算机都算是服务，正如在现实中你去超市，超市为你提供你所需要的产品，超市与网络中的一台服务器没有什么区别。就这个意义来说，我们至少都需要提供别人所需的，明白这一点是最重要的。
     2）明白了一台服务器就是为了提供服务之后，我们需要继续了解的是如何基于这些服务来开发别人所需要的功能。web services就是这种的一种高层次的技术，面向服务开发，我们现在不需要了解其底层的分布式计算等技术，我们首先需要注意的是，通过这种技术，我们可以更加的集中于服务的开发，所以我们现在要知道面向服务开发的技术对我们来说是多么的重要了。
    3）我们来继续考虑一下客户与服务器之间的交互。既然已明白了服务器就像超市那样为你提供了某些服务，那么自然的想到的开发方式是用户向服务器发出请求，服务器然后应答你的需求，自然而然的发展就是这样，因此这种是一种应答式的模式。事实上这种方式一直都很正确，但是对于程序员来说一直都没有成熟，程序员需要的是一种层次分明的模式来进行开发，他们的需求是根据最原始的要求那样：用户在浏览信息时，这就需要一个view层，不应该与客户端的内容联系在一起；而当需要提交一些内容给服务器处理时，这些内容也需要分离，作为一个model层；最为如何处理这些数据，则是服务器的问题，处理的方式是control层。这三层需要严格分离，同时这三层之间都是松散的，并各自都可以重用，这样在开发过程中就可以脉络清晰，具有更加高的效率。
          但是事实上，技术并没有向我们想象中的那么统一，比如在html文本本来作为一个通用的标准，就我认为，作为web层的表示内容基本足够，当需要动态反馈内容插入的时候，我觉得应该通过一个模板来插入，这也是我推荐模板式的而不是jsp等内容的原因之一，但是事实上很多框架都与web层紧耦合，破坏了可观性，同时也增加了开发过程的难度，这点在降低耦合性上，tapestry的模板机制用的非常棒；在control层上，这里应该提供所有的逻辑处理，这些处理也必须可以重用才行，但是技术一直都没有很好的向这个方向发展，不过，最近的spring-webflow在这方面的努力比较多（里面的根据状态来考虑用户的思想是一个很有趣的问题）。在这层上，有个很理性化的问题，那就是验证问题，验证就我认为，很多地方应该是服务器问题（除了基本的js浏览器脚本验证），所以应该纳入control层上，而且要针对那些模型对象，这也是我比较赞同spring中的验证的基本思想；在model层就没有什么好看头了，主要通过容器来把这些模型与其他结合就行了，这些类建议一般都应该为pojo类，并应该能serializable，同时都是使用orm工具来进行数据库访问。
      4）事务处理的技术，应该提供提交，回滚等事务处理功能。在这方面，spring做的不错，轻型的容器事务管理功能。
      5）IoC与Mock：如何把那三层松耦合的内容整合在一起？这就是容器的功能所在了，IoC的容器提供了极为强大的整合类的功能，降低了耦合行。Mock对象与Cuckoo Pattern的应用也是紧密相关的，这些内容在现代的AOP开发过程中经常可以看到。