We’re using Spring jdbcTemplate for implementing the service layer right now but at some point in future we’d like to move to hibernate. I am concerned whether the way our current service layer is designed will be efficient when we move to Hibernate.
Currently we have: I’ve left out details for clarity
Datasource in context xml
<bean id="dataSource" destroy-method="close" class="...BasicDataSource">
<property name="" value="" />
<property name="" value="" />
<property name="username" value="" />
<property name="password" value=""/>
</bean>
Service classes
@Repository
public class MyService {
private JdbcTemplate jdbcTemplate;
@Autowired
public void setDataSource (DataSource ds) {
this.jdbcTemplate = new JdbcTemplate(ds);
}
@Transactional
public void myTransactions () {...}
}
Controller:
@Autowired
private MyService myService;
I’ve seen a lot of implementations of hibernate service layer in spring mvc and most of them use an interface. What would be the benefit of adding an interface? And should I be adding an interface into my design? Would that make things easier when transitioning in to hibernate?
The only suggestion I have is to use interfaces and use an anemic domain model. This way you can switch interfaces implementation with spring with little effort.
And that is the benefit you get using interfaces.
Suppose that you have this packaging and classes:
and then you want to switch to hibernate, this way you do this structure
Then it is pretty simple to switch from jdbc to hibernate in spring if you use annotations in your daos:
instead of this:
you change it for this:
And thats it, you can switch your daos implementation without change your types in your services.