Java Ajax开发的技术选型

Java Ajax开发的技术选型

最近在为一个项目做前期准备，当然主要是我自己做了，所以要为自己的喜好选择一些顺手的技术。我一直认为基于Ajax的B/S架构绝对是以后图形界面程序的大一统，所以肯定就不用C/S架构了。以前虽然用ASP.NET开发过一些系统，上手是简单，但是对于大型应用来讲肯定是不行的啦，还得用万金油的Java。JSP/Servlet技术都以前摸过，但现在不是更流行模板技术吗？于是花了几天研究了一下，结果很失望...算了，还是用JSP吧，为什么呢？

其实原因就一句话：好的技术必须达到两个“方便”：写起来方便，改起来方便。模板技术的好处是什么？跳过了JSP到Servlet的转换？还是理论派所鼓吹的纯粹的“MVC”架构、界面呈现与业务逻辑完全分离？首先我们这里没有美工，所有的活儿都得自己干，其次，如果按照现代的Web设计思想，HTML只应该负责界面结构，这一点应该是程序员负责的。而界面的布局和美化是CSS干的活儿，这才是美工需要做的：为整个网站设计统一的CSS。

另外为什么不用JSP之外的杂七杂八的技术，最关键的一点是JSP天生具有和URL严格对应的特性：JSP放在哪个目录，名字是什么，对应的URL就是什么样的。而其它技术基本都涉及到Servlet，Servlet最要命的就是需要在配置文件中写上和URL的对应关系，写起来问题当然不大了，可是以后要改起来，肯定得两头一起动，如果项目规模很大，想想都恐怖。

JSP一个页面对应一个URL对应一个独立的功能，而且其中内嵌的可是标准的Java代码，要使用模板库，还得学那些特有的表达式。而且基本任何程序开发工具、网页设计工具都支持JSP：语法高量、代码补全、自动纠错等等都是我所喜欢的。至于JSP的缺点我认为在Ajax应用中都是历史了，比如Ajax应用基本上一个页面就是一个独立的功能，不会出现以前一个功能多个页面来回跳转的情况，所以Structs之类的MVC框架也就不需要了；另外Ajax业务逻辑很大程度上依赖于JavaScript，所以JSP中页面和代码混杂的情况也会很少出现，JSTL标签库等高级技术完全可以不用，我所需要的只是简单的<%%>。而我的JSP页面也就分两类：一类可以看作就是静态页面，零星出现一点点<%%>；另一类是和JavaScript交互、产生XML、Json数据用的，全部都是Java代码，包含在从开始到结束的一个大的<%%>中。这样一来，整个架构就非常清晰明了了，呵呵，可能有同学会问第二类JSP为什么不用Servlet技术？原因很简单：Servlet和URL的对应关系必须写在配置文件中。我不是不喜欢配置文件，而是反对在配置文件过多体现系统的业务逻辑，业务逻辑是会变的，让配置文件跟着变，太难受了...