简单的jdbc包装器 [英] simple jdbc wrapper

问题描述

要在我们的应用程序中实现数据访问代码，我们需要一些框架来包装jdbc（由于可伸缩性，ORM不是我们的选择）。

To implement data access code in our application we need some framework to wrap around jdbc (ORM is not our choice, because of scalability).

最酷的框架我曾经使用的是 Spring-Jdbc 。但是，我公司的政策是避免外部依赖，特别是spring，J2EE等。
所以我们正在考虑编写自己的方便的jdbc框架，其功能类似于Spring-jdbc：行映射，错误处理，支持java5的功能，但没有事务支持。

The coolest framework I used to work with is Spring-Jdbc. However, the policy of my company is to avoid external dependencies, especially spring, J2EE, etc. So we are thinking about writing own handy-made jdbc framework, with functionality similar Spring-jdbc: row mapping, error handling, supporting features of java5, but without transaction support.

有没有人有编写这样的jdbc包装器框架的经验？
如果有人有使用其他jdbc包装框架的经验，请分享您的经验。

Does anyone have experience of writing such jdbc wrapper framework? If anyone has experience of using other jdbc wrapper frameworks, please share your experience.

提前致谢。

推荐答案

我们编写了自己的包装器。这个话题值得一篇论文，但我怀疑我是否有时间写它，所以这里有一些要点：

We wrote our own wrapper. This topic is worthy of a paper but I doubt I'll ever have time to write it, so here are some key points:

• <我们接受了sql并没有试图隐藏它。唯一的调整是添加对命名参数的支持。参数很重要，因为我们不鼓励使用动态sql（出于安全考虑），我们总是使用PreparedStatements。

• we embraced sql and made no attempt to hide it. the only tweak was to add support for named parameters. parameters are important because we do not encourage the use of on-the-fly sql (for security reasons) and we always use PreparedStatements.

进行连接管理，我们使用Apache DBCP。这在当时很方便，但目前还不清楚现代JDBC实现需要多少（这方面的文档缺乏）。 DBCP还汇集了PreparedStatements。

for connection management, we used Apache DBCP. This was convenient at the time but it's unclear how much of this is needed with modern JDBC implementations (the docs on this stuff is lacking). DBCP also pools PreparedStatements.

我们没有打扰行映射。相反（对于查询）我们使用类似于Apache dbutil的ResultSetHandler，它允许您将结果集提供到一个方法中，然后可以将信息转储到您喜欢的任何地方。这更灵活，实际上为行映射实现ResultSetHandler并不困难。对于插入/更新，我们创建了一个通用记录类（基本上是一个带有一些额外铃声和口哨声的哈希映射）。行映射（对我们来说）最大的问题是，只要你执行有趣的查询就会陷入困境，因为你可能有字段映射到不同的类;因为你可能有一个分层的类结构但是一个扁平的结果集;或者因为映射很复杂且与数据有关。

we didn't bother with row mapping. instead (for queries) we used something similar to the Apache dbutil's ResultSetHandler, which allows you to "feed" the result set into a method which can then dump the information wherever you'd like it. This is more flexible, and in fact it wouldn't be hard to implement a ResultSetHandler for row mapping. for inserts/updates we created a generic record class (basically a hashmap with some extra bells and whistles). the biggest problem with row mapping (for us) is that you're stuck as soon as you do an "interesting" query because you may have fields that map to different classes; because you may have a hierarchical class structure but a flat result set; or because the mapping is complex and data dependent.

我们内置错误记录。用于异常处理：在查询中我们捕获并记录，但是对于更新，我们捕获，记录和重新抛出未经检查的异常。

we built in error logging. for exception handling: on a query we trap and log, but for an update we trap, log, and rethrow an unchecked exceptions.

我们使用提供的事务支持包装方法。调用者提供执行事务的代码，我们确保事务得到妥善管理，不会忘记完成事务并且内置回滚和错误处理。

we provided transaction support using a wrapper approach. the caller provides the code that performs transaction, and we make sure that the transaction is properly managed, with no chance of forgetting to finish the transaction and with rollback and error handling built-in.

稍后，我们添加了一个非常简单的关系方案，允许单个更新/插入应用于记录及其所有依赖项。为了简单起见，我们没有在查询中使用它，我们特别决定不支持删除，因为使用级联删除更可靠。

later on, we added a very simplistic relationship scheme that allows a single update/insert to apply to a record and all its dependencies. to keep things simple, we did not use this on queries, and we specifically decided not to support this with deletes because it is more reliable to use cascaded deletes.

迄今为止，这个包装器已成功用于两个项目中。当然，它是轻量级的，但是现在每个人都说他们的代码是轻量级的。更重要的是，它提高了程序员的工作效率，减少了错误的数量（并使问题更容易被追踪），并且如果需要，它相对容易追踪，因为我们不相信为了提供漂亮的架构而添加大量层。

This wrapper has been successfully used in two projects to date. It is, of course, lightweight, but these days everyone says their code is lightweight. More importantly, it increases programmer productivity, decreases the number of bugs (and makes problems easier to track down), and it's relatively easy to trace through if need be because we don't believe in adding lots of layers just to provide beautiful architecture.

这篇关于简单的jdbc包装器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！