Web应用开发模式选择与建立

本文撰写于新项目开始阶段,手头上有正在准备改造一个Java Web的项目。项目本身的功能和技术要点并不复杂,主要问题是集中在用户操作便捷性和数据展现方面的问题。因此这个项目的第一阶段是针对这些用户操作层面的问题做一些改动。经过一段时间的代码阅读,发现如果依然维持现有代码的体系改动为新版本的界面需求的话,尤其是考虑到未来的维护性要求,页面和后台交互的数据交互模型也需要考虑起来了,因此在这个过程中也就形成了本文。

在目前的流行的JAVA Web开发模式中,页面数据还是基于JSP或者模板模式开发的。那么就意味这JSP页面或者模板都需要经过编译才能够反馈并展示给用户。那么就意味着html页面内部会分布着很多的标签或者模板的tag数据。尽管模板技术提供了一定的界面定制的可能性,但是对于界面功能调整来说仍然存在复杂的地方。虽然使用这些技术可能降低后端开发人员对前台页面渲染技术的关注,但是却增加了前端人员对界面功能维护的难度。

现今SSH框架或者SSH框架的各种变体还是很受大众欢迎的,当然也有后起之秀,诸如Play!,Play! 2,Wicket,Apache Click等。在各种会议上也有关于如何选择Web开发框架的讨论和介绍,这里我并不想对这些讨论进行重复申述。如果有兴趣的话,可以Google或者访问以下几个地址(如果不能访问,请学习如何翻墙):

  1. How to choose a web framework and be surprised
  2. Choose the Right Java Web Development Framework
  3. Choose Java Web Framework

作为一个Web开发人员,无论你是新手还是老手,相信或多或少的了解了诸如MVC、MVVM、MOVE开发模式的各种概念。我也不准备针对这些概念进行更多的说明。如果有不明白的地方,可以通过下面的一些链接获得一点信息:

  1. 百度百科–MVC模式
  2. 百度百科–MVVM模式
  3. MVC模式不好用?何不试试MOVE

在之前的项目中,我主要使用的Java Web框架是Struts,也偶尔使用过Spring MVC,最近还使用过Play! 2。这里我不会比较这些技术框架的性能上的差异和具体实现细节上的不同。就我个人来说,我觉得Play! 2是非常不错的JAVA Web框架选择,但是它仍然不能让我满意。主要是基于它的模板技术以及对JAVA语言的支持偏弱。因为Play!2更多的是偏向Scala的,如果要完全发挥Play的作用,还需要学习Scala语言。

其实我下面所讲的内容跟JAVA Web框架选择本身并没有很直接的关系,只是出于我作为一个JAVA开发人员的角度来说,我更多也是围绕JAVA方面来描述。

前后端分离,以数据服务为中心

前端页面交互部分应当与后端数据处理部分分割开来,意即页面和后端完全通过JSON或者其他数据格式进行数据交互。这样就意味着后端服务器只提供数据服务,这些服务包含数据接受与返回,接受后验证等多个部分,服务的内部处理结果都以JSON形式返回给前端页面。前端页面根据相应的返回数据进行数据展示、页面提示、服务数据校验结果等。

这么做的好处有:

  1. 节省页面功能调整难度,避免前后端混杂带来的困难。将专业的事情交给专业的人来处理。
  2. 降低语言耦合度,容易切换开发语言。随着数据服务的提供,这些部分的数据可以给更多的WEB开发语言。除了支持JAVA语言外,还能提供给其它语言的开发程序使用。 3.移动数据交换接口。这里主要针对Web-APP来说,可以更方面为移动中端的数据请求提供服务。

前端模块化,组件化,进一步隔离页面交互与数据结果

前端页面也应提倡模块化、组件化开发模式。在以往的开发过程中,经常可以看到各种JS文件和代码的各处分布。由于缺乏模块化和组件依赖性的管理,导致对于JS代码维护的成本不小。也使得JS本身的测试覆盖一直不高。
随着Web2.0的发展以及NodeJS等服务端JS的兴起,对于JS的各个方面的研究也与日俱增。
对于JS文件的依赖管理和异步加载的管理,涌现了RequireJSSeaJSHeadJS等管理库,这些组件都能很好根据模块定义的需求来进行JS文件依赖的管理。
使用Javascript MVC 库。出于同样的原因,MVC的理念也从后端应用发展到前端页面交互层面,并且已经取得非常的发展。比如BackboneJS、SpineJS、EmberJS等。对于这些框架的优劣,我是没有发言权的,因为我只使用过其中的一两种。如果你想知道如何选择前端MVC框架,可以访问以下链接来深入了解:

  1. 基于MVC的JavaScript Web 富应用开发–图书
  2. The Top 10 Javascript MVC Frameworks Reviewed
  3. HTML5 TODO应用的各种MVC实现
  4. Javascript MVC最佳实践 –个人技术博客.

简化后端数据处理流程

从WEB开发的角度来说,Web数据服务不能仅仅是根据请求提供相应的数据结果而已,还应当有数据验证的结果。比如用户登陆校验、用户在线失效校验、数据提交校验、异常结果编码等。
将页面渲染和跳转的部分剥离后,后端引擎对于前端页面交互来说仍然需要处理两个地方:

  1. 静态资源的处理
  2. 伪页面的返回
  3. 前端页面数据渲染方法

1,静态资源的处理。
后端服务器引擎,仍然需要处理静态资源文件的请求,比如图片,CSS样式,JS文件等。

2,伪页面的返回
在主要模块之间跳转的的数据来说,后端服务仍然需要返回无数据的页面文件。

3.前端页面数据渲染方法
这些页面的数据填充则由前端根据request请求参数或者其它方法再次获得实际数据,并在客户端进行填充渲染。

需要关注的问题

  1. Session管理
  2. 用户在线与自动离线跟踪
  3. 抢占登陆与用户踢出处理

在这种情况下用户在线的判断更多的依赖Cookie的存储和判断了。

我个人推荐的几种组合方案:

  • 前端组合
    1,SeaJS+BackboneJS
    2,SeaJS+Module(不采用MVC模式。只遵循模块化依赖)。

  • 后端组合:

    1. MVC方面(视图被弱化为数据服务)仍然可以选择常用框架或者原生Servlet。推荐使用Spring MVC,NDOF(基于Servlet的基础包装,接近Spring MVC),Struts2等。
    2. 逻辑处理部分可以采用Spring,或者简单包装的逻辑服务层面。
    3. 数据访问层的选择则更丰富,可以选择如Hibernate、ibatis、Spring JDBC,简单的可以自己包装的DAO层。

我之前听过雪球网的同学分享他们使用NodeJS的地方(雪球NodeJS半年经验谈),就采用类似的方法。不过他们相对更激进,为了考虑到前端开发人员的问题,直接弃用JSP页面方案(理由是JSP太难维护),转换为NodeJS的产品,而后端数据来源还是由之前的JAVA应用提供,中间需要注意的是他们还特别增加了第三方的session管理(这是由于当时NodeJS ExpressJS不提供Session管理,据说express 3.0提供了。)