NO XML ，NO ANNOTATION，2个核心类解决单表和多表连接问题

背景介绍一下：
1）大家都觉得jdbc原生语句最好用，效率最高，使用最灵活，原因在于他比较底层，借助于人脑的思维，化简了很多问题。但是，他写起来并不高效。
2）ORM工具的出现，为了提高编写效率，封装对象，避免了SQL的接触。但是他不够灵活。
3）于是，ibatis， Mybatis就出现了，他走了中间路线。

问题：
1）所有的ORM工具，对于join都支持不好。原因在于这些ORM太注意OO思想，需要在早期设计POJO时就要考虑多表关系。
这对于以后的更新、升级、维护带来了很多麻烦。
2）如果发现问题，需要修改为适合自己流程的ORM需要改动一些文件，对与老手可能不是问题，对于新手就要阅读很多文件，才能动手。


前提假设：
1）首先说明，这个ORM并不是说流行的ORM好，只是解决了上面提到的2个问题。请大家手下留情。文明回帖。
2）生成SQL模板的程序已经写好，在源码中。SQL参数的命名规范是ClassName_FieldName，这个是最重要的。
3）使用静态变量存储SQL模版，好处是如果以后更新代码，只要修改模板，可以修改所有涉及到的SQL。利用IDE提前发现错误。也可以使用XML存储SQL模板，这个更易阅读。
4）POJO封装工具也已经生产。



新的思路：
1）sql语句中的参数传递。常见的一些传递方法都是(String sql,Object[] objs)，这样我们需要考虑传递顺序。注解的方式可以解决，但是需要手工去写，太麻烦。而且本ORM是反对注解的。所以，使用Map传递。自己拼接SQL语句。而且拼接时需要注意@{}和@[]的不同，这个是我工作中遇到的一个小问题。
2）无论单表查询还是多表查询，结果都是2维表。这样就可以用List<Map<String,Object>>这样的数据类型存储。所以，本ORM不建议一步到位至POJO，而是再加一层封装，参数就是这个List<Map<String,Object>>到POJO。原因如下：
a）这个框架统一，Map作参数，Map做结果，这是最灵活的。
b）如今很多框架都用JSON，所以没有必要再封装成POJO。
c）如果涉及到多表JOIN查询，我们可以从这个Map结果中提取出多个POJO。
3）修改容易，只有2个核心表，代码一看就懂。方便修改。

存在问题：
1）是否存在线程安全问题，需要各位大牛帮助解决，我目前没有发现。
2）性能问题，考虑的比较少。

更多的不说了，源代码上传。作为讨论，请勿乱喷。