改进架构，实现动态数据源，结束java开发生活

如何不用写java代码来完成开发？

对于大部分的产品和项目来说，页面变化是非常头痛的事情。每次小功能上线，新客户到来，都需要进行定制改造，不断的开发维护。每次开发一方面要改动页面，一方面要改动服务器代码，然后部署。而借助动态数据源，可以不用开发后端应用，直接完成功能开发。

新功能开发时，只需要定义需要的数据格式和获取方法，如通过xml上传1个sql语句，系统根据sql语句自动提取数据并转成通用的格式。开发过程中，后台java开发部分只是写好sql并且上传，这样前台通过某一个servlet可以动态的读取执行sql，并将结果按照json返给前端，以后所有的开发只需要前端做ajax实现页面即可。

完整业务流程如下：

1. 用户在前端操作，如需要读取经济类图书。

2. 前端js判断是什么操作，然后发送ajax请求到：http://services.guzz.org/commonServlet?id=f2354239sfASASFASfasf6&catId=47&keyword=jingji.....

3. 服务器端有一个类似dispatcher-servlet的东西（我们这儿的commonServlet），拦截请求，根据id知道加载数据需要执行名称为f2354239sfASASFASfasf6的sql文件，执行时需要参数：catId=47和keyword=jingji

4. commonServlet从文件系统中读取f2354239sfASASFASfasf6.xml文件（这个文件在一个隐藏的目录下，从浏览器是不能直接获取到的；集群环境会存放在集中存储上），解析sql以及对象映射ORM。

5. commonServlet打开数据库连接，根据sql构造查询语句，将第一步传入的参数全部作为命名参数传给查询语句，执行查询。

6. commonServlet把查询的ResultSet根据ORM转成java类，再转成json，返回前台。

7. 前台根据json构造出页面并展示。结束流程。

在整个过程中，有2个关键步骤，一是动态加载SQL并进行ORM映射，一是自动进行sql所需要参数的类型转换和匹配，进行命名查询。如果系统规模较大，还需要解决查询时分库分表的问题。对于这种sql使用方式，由于在系统上线时，并不知道以后会用哪些sql语句，我们称作动态SQL。

实现方式：

步骤1. 实现servlet。定义一个普通的servlet，或者jsp，或者webwork/spring action，接收参数，获取到sql的id，以及所有传入的参数，然后转入处理类处理。处理完成后，将返回结果转成json返回前端。

步骤2. 实现动态SQL加载与查询。处理类根据id加载sql并执行，返回数据库查询结果。guzz 1.2.8 beta2提供了动态SQL服务，根据此服务可以直接实现此功能。详细说明：http://code.google.com/p/guzz/wiki/TutorialDynamicSQLService

好处：

实现以后，基本上后台开发就会很稳定很稳定了，大部分的工作只是前端做页面。可以大幅度的降低开发成本，提高开发进度。

上面的实现是以上传文件来定义和管理sql，也可以通过数据库来管理。这样管理起来更加简单。

如果使用guzz作为动态SQL提供者，可以自动获得命名查询，类型自动匹配（转成枚举类型都可以），分库，自动分切表，自定义属性表等附加支持。

啧啧～～

多表查询怎么办？

自己写的sql，想怎么关联怎么关联呗……

第一次有人给我介绍这种概念时，我觉得震惊，很有意思，也很有用。原来还可以这么做。

我们开发与使用了下，都挺好用的，整理出来结果发现JE上大家对此毫不感冒，难不成大家有更好的方法。欢迎分享。

搞得没名堂，如何完成一个多步的事务处理操作，难不成一个事务步骤一个http request。

对于多字段表的多条件查询，个人经验，这种方式还是挺好的。
曾经有一个项目我就是这么设计，前台拼HQL/SQL传到Server端执行。
当然，Server端的校验是不可少的，以防止SQL注入之类的杯具发生。
不过这种办法，我当时仅仅是做查询之用。其他的操作，还是按照传统来

DROP TABLE ....

这个和myibatis（ibatis）区别不是很大吧，我大体看的怎么这么像啊

很难理解只用SQL就能实现一个应用，业务逻辑放在哪里？

他说不写java代码~