[
https://issues.apache.org/jira/browse/EMPIREDB-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14910123#comment-14910123
]
Ivan Nemeth edited comment on EMPIREDB-227 at 9/28/15 7:42 AM:
---------------------------------------------------------------
Hi Rainer,
thanks a lot.
You're right, copying each property can be error-prone, but it's the developers
decision how to extend the EmpireDataReader interface. Personally I don't like
automatic mapping of bean properties for some reasons*, that's why I've used
this kind of mapping. For bean-property mapping a single class can be written.
public class BeanPropertyDataReader<K> implements EmpireDataReader<K> {
private Class<K> clazz;
public BeanPropertyDataReader(Class<K> clazz) {
super();
this.clazz = clazz;
}
public K read(DBRecordData record) {
K result = null;
try {
result = clazz.newInstance();
} catch (Exception e){
//error handling
}
record.getBeanProperties(result);
return result;
}
}
Maybe your enum handling solution can be part of the core DBReader and DBRecord
classes, because it is useful in other scenarios also, not only in this
example.
(*) I think with bean property mapping your domain model is strictly tied to
the database structure and you lose a lot of freedom. For example you can't use
embedded objects (like Department in the example) and the domain property names
must match the table columns. Moreover on large resultset with numerous columns
some performance issues may arise. On the other hand you have to write the bean
mapper only once (like DepartmentMapper in the example), and use it everywhere.
Regards,
Ivan
was (Author: [email protected]):
Hi Rainer,
thanks a lot.
You're right, copying each property can be error-prone, but it's the developers
decision how to extend the EmpireDataReader interface. Personally I don't like
automatic mapping of bean properties for some reasons*, that's why I've used
this kind of mapping. For bean-property mapping a single class can be written.
public class BeanPropertyDataReader<K> implements EmpireDataReader<K> {
private Class<K> clazz;
public BeanPropertyDataReader(Class<K> clazz) {
super();
this.clazz = clazz;
}
public K read(DBRecordData record) {
K result = null;
try {
result = clazz.newInstance();
} catch (Exception e){
//error handling
}
record.getBeanProperties(result);
return result;
}
}
Maybe your enum handling solution can be part of the core DBReader and DBRecord
classes, because it is useful in other scenarios also, not only in this
example.
* I think with bean property mapping your domain model is strictly tied to the
database structure and you lose a lot of freedom. For example you can't use
embedded objects (like Department in the example) and the domain property names
must match the table columns. Moreover on large resultset with numerous columns
some performance issues may arise. On the other hand you have to write the bean
mapper only once (like DepartmentMapper in the example), and use it everywhere.
Regards,
Ivan
> Spring Integration
> ------------------
>
> Key: EMPIREDB-227
> URL: https://issues.apache.org/jira/browse/EMPIREDB-227
> Project: Empire-DB
> Issue Type: Improvement
> Reporter: Ivan Nemeth
> Attachments: empire-db-spring.zip
>
>
> Starting point for a Spring-Empire integration. Code is based on Spring's
> JdbcTemplate model.
> There are corresponding classes for Spring's RowMapper, RowCallbackHandler
> and ResultSetExtractor (EmpireDataReader, EmpireRowCallbackHandler,
> EmpireReaderExtractor).
> Two examples is inculeded:
> SampleSpringApp does the same as the spring example I've found on Git.
> EmployeeApp: on the same db but with a different apporach (dummy ORM style)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
