Сопоставление ResultSet с объектами Pojo

Хорошо, что действительно смущаю, что я создал стандартный класс pojo и его dao-класс для целей извлечения данных. Мне трудно понять базовую процедуру обработки настраиваемых данных запроса классу Pojo.

скажем, мой класс пользователя

public class User{
private int userId;
private String username;
private int addressId;
}
public class Address{
private int addressId;
private String zip;
}
public class UserDAO{
public void getUserDetails(){
String getSql = select u.userId, u.username, a.zipcode from user u, address a where u.addressId = a.addressId;
 //no pojo class is now specific to the resultset returned. so we can't map result to pojo object
}
}

теперь, как я должен моделировать это с моим классом pojo, как будто используя String для управления этим, тогда концепция объектно-ориентированного обращения исчезает, а также сложность будет возрастать и в будущем. любезное руководство!

Обновление для дальнейшего пояснения

Мы знаем, что мы можем сопоставить одни и те же объекты таблицы с тем же классом pojo, но когда запрос настраивается и возвращаются данные, которые не сопоставляются с каким-либо конкретным классом, то какова будет процедура? т.е. мы должны создать другой класс? или мы должны бросать эти данные в переменную String? любезно дайте также пример.

4 ответа

С этой целью вы можете использовать одну из реализаций JPA. Но поскольку вы хотите сделать это вручную, я приведу вам небольшой пример.

UPD:

public class User {
 private int userId;
 private String username;
 private Address address; // USE POJO not ID
}
public class Address{
 private int addressId;
 private String zip;
 List<user> users;
}
 public User getUserById(Connection con, long userId) {
 PreparedStatement stmt;
 String query = "select u.user_id, u.user_name, a.id, a.zip from user u, address a where a.address_id = u.id and u.id = ?";
 User user = new User();
 Address address = new Address;
 try {
 stmt = con.prepareStatement(query);
 stmt.setLong(1, userId);
 ResultSet rs = stmt.executeQuery();
 address.setId(rs.getInt("id"));
 address.setZip(rs.getString("zip");
 user.setId(rs.getInt("id"));
 user.setUsername(rs.getString("user_name"));
 user.setAddressId(rs.getInt("address_id"));
 user.setAddress(address); // look here
 } catch (SQLException e) {
 if (con != null) {
 try {
 System.err.print("Transaction is being rolled back");
 con.rollback();
 } catch (SQLException excep) {
 }
 }
 } finally {
 if (stmt != null) {
 stmt.close();
 }
 }
 return user;
 }
</user>

Вы не должны делать новый POJO для этого запроса, вы должны написать обычный запрос. И помните: ваша объектная модель является основной, таблицы в БД - это всего лишь способ сохранить данные вашего приложения.


Мы знаем, что мы можем сопоставить одни и те же объекты таблицы с тем же классом pojo, но когда запрос настраивается и возвращаются данные, которые не сопоставляются с каким-либо конкретным классом, то какова будет процедура? т.е. мы должны создать другой класс?

Динамическое создание экземпляра JPA позволяет вам определить запрос с POJO, конструктор которого определяет только поля и типы, которые вы хотите получить из базы данных.

Это выполнит выбор JPA, который вернет список. Если вам нужно изменить запрос позже, а столбцы не изменились, ваше POJO все равно будет работать. Если вы измените столбцы, то также измените POJO соответственно.

Примечание:

Необходимо указать полностью квалифицированные аргументы пакета и конструктора.

Тип Пользователь должен быть JPA-обозначенным или JPA-аннотированным классом сущностей.

СущностьManager находится в JPA EntityManagerFactory.

TypedQuery<user> q; 
String sql = "select new com.stuff.User(
int u.userId, String u.username, String a.zipcode) 
from User u, Address a where u.addressId = a.addressId";
List<user> list = entityManager.createQuery(sql).getResultList();
for(User u : list) {
 doStuff(u);
}
</user></user>

Динамическое создание экземпляров также удобно, когда вы хотите выбрать указанные столбцы, но избегайте этих столбцов с большими данными, например типами BLOB. Например, возможно, вам нужен список прокси POJO, который представляет собой полностью заполненную вещь, но сам по себе не полностью заполнен. Вы представляете список прокси, и когда пользователь выбирает его, вы делаете еще один запрос, чтобы получить полностью заполненный объект.

Ваш пробег может отличаться.


Там много ORM, которые могут это сделать, включая Hibernate, myBatis, JPA и spring -JDBC

spring -jdbc и myBatis дают вам подробный контроль над SQL, тогда как с JPA и Hibernate вы обычно отвлекаетесь от SQL.

Я предлагаю вам кое-что прочитать и выяснить, какой из них вам нравится, прежде чем запускать собственное решение.


Ваш вопрос:

We know that we can map same table objects with same pojo class,
but when the query is customized and there is a data returned 
which doesn't map to any specific class then what would be the procedure?

Если у вас есть 100 видов SQL, которые возвращают разные комбинации столбцов, может ли быть создано 100 различных POJO? Ответ "НЕТ, прекратите использование POJO".

Эта библиотека qood предназначена для решения этой проблемы, вы можете попробовать ее.

licensed under cc by-sa 3.0 with attribution.