面向组合子编程实验-SQL组合查询条件的简单实现

这段时间学习了ajoo的面向组合子编程系列，学习编程的最好方法莫过于动手做实验，因此把以前一个用于生成SQL组合查询条件的工具用CO实现了一把，由于对CO还一知半解，很可能存在画虎成猫的情况，砖头尽管砸过来，这个我已经有充分的思想准备
源码在附件里，TestExpression是Junit的测试类，使用思路就是根据包提供的基本条件表达式，组合成复杂的表达式，如：

public void testComplexExpr();{
		//((age >18 or (fullName is null and deptId = 001);); and forbid = false);; 
		Expression expr = Expressions.largeThanExpr("age","18");.or(
				Expressions.isNullExpr("fullName");.and(
				Expressions.equalToExpr("deptId","001");););.and(
				Expressions.equalToExpr("forbid", "false"););;
		IContext ctxt = new SimpleContext();;
		expr.execute(ctxt, result);;
		assertEquals("((age > ? or (fullName is null and deptId = ?);); and forbid = ?);",result.getExpression(););;
		assertEquals(3,result.paramSize(););;
		assertEquals("18",result.getParamValue(0););;
		assertEquals("001",result.getParamValue(1););;
		assertEquals("false",result.getParamValue(2););;
	}

你们的批评和建议就是我进步的动力，希望各位老大多提提批评和建议。
这个包暂时没有实现bind规则，发现好像用不着？

做了点修改，增加一个IContext接口，实现字段名绑定表别名。

这种思路类似于 Hibernate Criteria.

组合子本身做的不错。

不过，用错了地方。

SQL拼装采用组合子（比如包括Hibernate Criteria）这种思路，完全是画蛇添足，一无是处，成事不足，败事有余。

SQL本身就是一门很简洁优雅的可读性很好的DSL语言。为啥非要转换成这个丑陋的Java对象组装代码？

如果要动态拼装SQL， iBatis的SQL动态拼装是正确的思路。

Hibernate Criteria的组装看着不太舒服

不过hibernate3的filter我是很感兴趣的，提供了类似ibatis的sql拼装方式。

网络太慢，重复提交，麻烦版主删掉这个回复

有这么一种需求，需要在运行时通过AOP或动态Proxy拦截，添加查询条件，如果直接用SQL或者ibatis方式，比较难以实现，所以需要封装成Hibernate Criteria这种丑陋的Java对象。

用filter吧，反正看起来更清爽些！

这种需求，能真实或具体一些么？

比如下面这个简单的业务场景：
总经理可以查看所有的订单，张三可以查看金额500万以下的订单，李四可查看100万以下的订单，规则的金额要求可以在运行时调整，需要分页显示订单列表的时候，不大可能把所有的数据全取回客户端过滤，分页显示，这时，采用AOP或动态Proxy动态的根据后台业务规则和当前操作人的角色动态的添加查询条件，如果不用对象封装查询条件，比较难以修改查询条件。

直接在业务层根据业务规则拼SQL语句，不是很喜欢这种方式，而通过AOP或者动态Proxy，配合规则定义，比较容易实现这部分逻辑的分离。

这只是我解决这类问题的思路，不知道对付这种需求，分页查询，除了直接拼SQL，有更好的方式么？