在DAO层、ORM框架层、JDBC API层、DAO与JDBC之间的spring数据访问层、应用与数据库之间代理层实现数据库sharding优缺点分析：

1.DAO层

    优点：不受ORM框架制约，实现起来比较简单、易于根据业务特点进行灵活定制、无需解析SQL和路由规则匹配性能会稍微好些

    缺点：技术有一定门槛，工作量比依靠框架要大（用框架有学习成本），不通用，只能在特定系统中使用

2.ORM框架层

    两个方向：在实现O-R Mapping前提下同时提供sharding，从而成为一种分布式的数据库访问框架（类似guzz）

                    通过现有的ORM框架进行修改增强来加强sharding机制（产品有hibernate shard，但是目前表现不让人满意，主要它对hibernate限制过多，比如对HQL支持非常有限。而在mybatis层面目前没有成熟的相关框架）

           有人提出利用mybatis的插件机制实现sharding，但是该机制控制不到多数据源的连接层面，另一方面，离开插件层又失去了对sql进行集中解析和路由的机会。

3.在JDBC API层

    产品：商业产品dbShards

    优点：对整个应用程序来说完全透明，可以直接作为通用的sharding产品

    缺点：技术门槛和工作量不是一般团队能做的

4.介于DAO和JDBC之间的spring数据访问封装层

    产品：艾利集团研究院开源的Cobar Client

    优点：效果与基于JDBC API实现的方案基本一致，对上层透明，对sharding进行更改，可以平滑地过度，实现起来比基于JDBC API简单

    缺点：技术难度比较大，相对来说不是太大

5.应用服务器与数据库之间通过代理实现

    产品：Mysql Proxy（并未实现任何sharding逻辑，给开发人员提供嵌入sharding逻辑的场所，使用lua，技术方向匹配是个问题），amoeba（国人开发，实现读写分离与sharding的代理，通过xml进行配置，不过不支持事务，单节点也不支持）

    优点：对应用程序完全透明，通用型好，使用简单

    缺点：产品Mysql Proxy实现sharding逻辑需要考虑lua语言，amoeba不支持事务