jdbc还是ibatis？

你一个architect连决定用什么技术的权力都没有,还算什么architect啊?

题外话：有时候一个程序code没几行，底下XML暗涛汹涌，出点问题还真不好找。可能这也是代码生成的好处之一吧。

不过iBatis看起来还是挺简单，虽然没用过，不过似乎还不至于那么难调。我们用一套存储过程的Wrapper, 是代码生成的，挺方便。

ibatis允许配置DataSourceFactory。
我用dynamic proxy把所有的jdbc call都拦截了，这样调试起来其实更方便。

这个问题从一开始就不是一个技术问题。试图从技术的角度来说服同事用ibatis，效果自然不会好。

如果要从技术的角度来说的话，站在同事的立场，ibatis在技术上没有带来显著的好处。ibatis能实现的，或者自己用jdbc也能实现，或者他觉得没有必 要实现。每个人都倾向于选择自己熟悉的方案，因为心里有底。不用ibatis的好处是显而易见的：一、什么也不用学；二、拥有几乎无限度的灵活性。如果将来需要什么功能，凭着对 jdbc的熟悉，可以随时添加必要的功能。

要说服同事，就必须上到更高的台阶来看这个问题：是自己开发框架，还是用现成的。

用jdbc写简单的框架虽然有这样那样的好处，但坏处是致命的：维护成本。现在你们可能还不觉得什么，只是做了个很简单的框架而已。可是今天觉得缺少这个功能，就添加之；明天又觉得那个地方以前没有考虑到，再修改之。时间长了，这个简单的框架就会不再简单，到最后你们就会发现有了个自己的不怎么样的ORM框架。即时你们有意识地控制这个框架的规模，也还是很难。特别是对于技术素质好的人来说，没有办法容忍自己框架的这样那样的不好。结果就是，在这个框架中越陷越深。相对于用现成的开源框架来说，开源框架有一个team在维护，对你们来说就是0成本维护，而且还比自己维护自己框架的效果好。

自己开发框架并不是没有学习成本。开发框架的人是可以不用学，但以后再招人，如果用了现成的框架，可以直接招懂这个框架的人；如果自己开发框架，新招近来的人必须有一个学习的过程，而且更糟的是自己开发的框架还没有什么完善的文档。长远地看用自己的框架的学习成本反而比用现成的要高。

其实只要是用一个现成的框架，不管是ibatis还是hibernate还是spring jdbc template还是什么别的，都比自己开发一个框架强。这样你们可以把精力集中在解决领域问题上，而不是分散在维护自己的框架上。

我在工作中不得不用大量的精力维护我们自己的不怎么样的MVC框架和ORM框架。明天我离开这个公司，后来的人同样要花精力学习和维护这两个框架。

并不是绝对地反对做自己的框架。如果自己有独到的想法，可以实现现有的框架做不到的，完全可以开发一个新的框架。但是，如果真有这个需要，我也宁愿把这个框架开源。一来可以从别人的反馈中更好地发展这个框架，二来也可以有其他的人加入进来，共同发展它。同样是开发框架，比作为一个内部项目来开发就要强得多了。

基于这样的理由，我是坚决反对在公司内部发展自己的框架。建议你先和同事解决“开发自己的框架还是用现成的框架”的问题，然后再具体探讨用哪个框架。

你也不要局限在ibatis上。
提示一：也许spring jdbc template是一个比较好的折中
提示二：hibernate也可以用作jdbc框架
www.theserverside.com/tt/blogs/showblog.tss

我其实也反对开发自己的“框架”。自己的库还成。Framework嘛，现在一听这个词就头疼。


可惜，我们现在自己开发的Framework不管好不好，都顶着一个“公司标准，一致性”的大帽子，你不用都不行。

这个遗留系统里面自己的框架多了，有mvc, property, ioc, persistence。都是作的比较古怪，灵活性，可用性和简单性都比较差，跟业界标准也不那么兼容。

比如，persistence框架里自己弄一个MyConnection，而不是java.sql.Connection。
property框架自己内部通过某种逻辑决定ClassLoader，而这个ClassLoader从外界无法得到，所以也无法和别的开源框架兼容。自己弄的MyProperties不实现java.util.Map。

等等等等。

不过，软件这东西，真是公说公有理的事情。就一个“一致性”就几乎可以枪毙一切改进措施了。

spring template我们暂时还是不用。不太想引入spring的依赖。毕竟我们还不到替换自己的ioc的时候。

commons dbutil倒是轻量的多。不过和我们的自制persistence不太兼容，也不能帮我们做cache。

hibernate嘛，要的改动就大得多了，学习曲线也陡，我自己都不能说服自己采用。毕竟现在的persistence框架上和概念上和ibatis是最接近的。

我觉得你还是在从技术层面看问题，还是过于急迫地进入细节。

第一步，不预设任何方案，说服同事选择开源框架，而避免陷入自己开放又一个框架的泥潭；
第二步，你们一起选择一个合适的开源框架。

到底选择哪一个，等解决了第一步以后再说。如果ibatis真的是最适合你们的方案，我相信一旦你们进入第二步，在同事的参与下你们最终会选择ibatis。与其去推销自己的选择，不如引导他作出同样的选择。

ibatis在遗留系统改造中使用，它对原有JDBC代码的替换可以说是思路清晰，相当容易上手！

Hibernate用在新设计的系统中，也很容易掌握，难点在于，如果像我所遇到的，表与表之间存在外键，存在多对一和多对多的关系的时候，设计上的不合理就会在运行效率中明显的体现出来，这差点让一个项目在中途进行大规模重构！

使用jdbc，可以使用Spring对jdbc的封装，感觉还是比较好用的，
如果你不打算使用Spring，也可以使用Template method模式和
回调方法来封装对jdbc的低级操作（具体可参见Spring的实现）。
当然使用ibatis可以大大减少许多低级操作，而且学习非常容易，
感觉还是有必要在公司推广。当然hibernate是不错的选择，不过
学习难度比ibatis大点。
不过我一直对持久层技术存在一些疑惑：
无论是jdbc、ibatis、hibernate,当使用Dao模式进行封装分离出
持久化层时，当业务需求增加或变化时，dao往往也许要发生变化，例
如查询文章，以前根据title,现在又需要根据id，这就需要增加新的
方法，觉得很不爽。如果能够直接设置Example的状态，根据这个对象
的非null属性来查询（当然需要支持复杂的情况，如title满足简单的
正则表达式，整数的范围等）。只需要一个方法，传递一个对象就可以查
询满足的对象。rails的ActiveRecord，能够动态的产生查询方法（
find_by_id(),find_by_title()）,没有了dao层，但需求增加时，不需要修改原来的代码，感觉还是不错的。

既然想到了 何不搞个出来 这段话下面贴个附件带上你的demo 该有多漂亮 呵呵

ajoo不是写过jdbc template么？

http://www.iteye.com/topic/7068

和你同事那个差不多吧，一个继承，一个组合