我们编写了自己的包装器。这个主题值得写一篇论文,但是我怀疑我是否有时间写它,所以这里有一些关键点:
我们接受了sql,并没有尝试将其隐藏。唯一的调整是添加对命名参数的支持。参数很重要,因为我们不鼓励使用实时sql(出于安全原因),并且我们始终使用PreparedStatements。
对于连接管理,我们使用了Apache DBCP。当时这很方便,但目前尚不清楚现代JDBC实现需要多少资源(缺少有关此文档的文档)。DBCP还池了PreparedStatement。
我们没有理会行映射。取而代之的是(用于查询),我们使用了类似于Apache dbutil的ResultSetHandler的方法,该方法使您可以将结果集“馈入”到一个方法中,该方法然后可以将信息转储到您想要的任何位置。这更加灵活,实际上,为行映射实现ResultSetHandler并不困难。对于插入/更新,我们创建了一个通用的记录类(基本上是一个带有一些额外花哨的hashmap)。行映射(对我们而言)最大的问题是,您在执行“有趣的”查询时就被卡住了,因为您可能有映射到不同类的字段;因为您可能具有分层的类结构,但结果集比较平坦;或者因为映射是复杂的并且依赖于数据。
我们内置了错误日志记录。对于异常处理:在查询中,我们捕获并记录,但在更新中,我们捕获,记录并重新抛出未经检查的异常。
我们使用包装器方法提供了交易支持。调用者提供执行事务的代码,并且我们确保正确管理事务,不会忘记完成事务,并且内置回滚和错误处理功能。
稍后,我们添加了一个非常简单的关系方案,该方案允许将单个更新/插入应用于记录及其所有依赖项。为了简单起见,我们没有在查询中使用它,并且我们特别决定不支持使用deletes,因为使用级联删除更可靠。
迄今为止,该包装器已在两个项目中成功使用。当然,它是轻量级的,但是如今,每个人都说他们的代码是轻量级的。更重要的是,它提高了程序员的生产率,减少了错误的数量(并使问题更易于查找),并且在需要时相对容易地进行了跟踪,因为我们不相信仅仅为了提供漂亮的体系结构而增加很多层。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)