我正在使用 JDBC（和 spring-jdbc 的 jdbcTemplate）在 java Web 应用程序中访问我的数据库。我有许多不同的不同查询，其中一些查询是我连接到那边的表，一个是带有子查询的查询，一个是在此处使用 group by 等等。
通常我需要结果只是为了显示由 JSP 生成的特定表，因此我可以使用方便的 queryForList 方法，该方法返回一个 List>，这是一个列表，其中每行都由将列名称映射到值的映射表示。在 JSP 中这很好，无论如何都没有编译时类型检查，没有 Eclipse 等属性的代码完成。
但有时我有 java 代码来处理查询结果，我认为不使用映射会很有帮助，但是对于真实对象，主要是为了在编译时检查属性是否确实存在，是否具有正确的类型，当然还有代码完成。
但如果我想要的话，我需要为每个查询编写一个对象，该查询可能是许多对象（除了 setter 和 getter 之外什么都没有的代码页）。
处理这种情况的最佳方法是什么？就写那些该死的对象吗？或者有更好的方法吗？
I am using JDBC (and spring-jdbc's jdbcTemplate) to access my database in a java web application. I have many different varying queries, some where I join to the table over there, one with the subquery that, one using a group by here etc. etc.
Oftentimes I need the result just to display a particular table that is generated by JSP, so I can just use the convenient queryForList method that returns a List<Map<String, Object>>, a List with each row represented by a map that maps column names to values. In JSP this is just fine, there is no compile time type check anyway, no code completion for properties by eclipse etc.
But sometimes I have java code to process the query result and I think it would be helpful to not work with maps, but with real objects, mainly for having a compile time check whether to properties really exist, have the correct type and of course to have code completion.
But if I want that I need to write an Object for every single query which may be many objects (pages of code with nothing but setters and getters).
What would be the best way to deal with that situation? Just write those darn objects? Or is there a better way?
发布评论
评论（2）
您希望编译器理解您的对象模型，因此（至少在 Java 中）您将需要创建它，恐怕。
一个不错的 IDE 将提供从成员变量生成 get/set 方法的选项，这可以节省时间。如果对象模型的存在纯粹是为了在 JDBC 查询上应用一些语义而不是业务逻辑，那么公共成员可能是合适的，从而避免了对 J2EE 风格的 getter 和 setter 的需要sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html" rel="nofollow">传输对象 模式。只需注意其中潜入的业务逻辑，不要忘记 equals() 和 hashCode()。
不过，在 Spring JDBC 中，有一些帮助可用于与对象进行映射，例如 RowMapper 和 MappingSqlQuery。您可能还想查看对象关系映射框架，例如 Spring ORM< /a> 为自己节省一些精力。我认为这些方法节省了在 SQL 之间编写翻译代码、管理事务和数据库模式的时间 - 我们仍然需要创建对象模型。
You want the compiler to understand your object model, so (in Java, at least) you will need to create it, I'm afraid.
A decent IDE will provide options to generate get/set methods for you from members variables, which can be a timesaver. If the object model exists purely to apply some semantics over the JDBC queries and not business logic, perhaps public members are appropriate, avoiding the need for the getters and setters in the style of the J2EE Transfer Object pattern. Just watch out for business logic creeping in there, and don't forget about equals() and hashCode().
There is some help available for doing the mapping to and from your objects though, in Spring JDBC, like RowMapper and MappingSqlQuery. You may also want to check out Object Relational Mapping frameworks like Spring ORM to save yourself some effort. I think these approaches save time in writing translation code to and from SQL, managing transactions and the database schema - we still need to create the object model.
正如 Brabster 提到的，RowMapper 和 MappingSQLQuery 可以帮助您将 sql 结果集转换为对象。但我知道您担心的是您并不总是从查询中提取整个对象，有时您会提取对象的组合（通过执行 sql 连接）。
因此，如果我理解正确的话，您基本上想知道是否也必须为每个对象组合创建类？
简单的答案是否定的，您不需要为每种类型的联接查询创建自定义类，但是在没有适当的 ORM 的情况下，您必须为每种类型的联接提供 RowMappers（请注意，ORM 中的 M 代表映射）。由于spring的JDBC框架不是ORM，它要求您为每个查询提供映射逻辑。如果这听起来太麻烦了，欢迎来到 ORM 世界:)
As Brabster mentioned, RowMapper and MappingSQLQuery are there to help you in converting your sql resultsets into objects. But I understand that your concern is that you don't always extract whole objects from queries and sometimes you extract a combination of objects (by doing sql joins).
So if I understand correctly, you are basically wondering whether you'll have to create classes for each of these combination of object too?
Simple answer is no, you don't need to create custom classes for each type of join query, but in absence of a proper ORM, you'll have to provide RowMappers for each type of join (note that M in ORM stands for mapping). As the spring's JDBC framework is not an ORM, it asks you to provide the mapping logic for each query. If this sound too much work, welcome to the ORM world :)