Java - DAO Layer or Plugin

Question

Hi,

I work on the JBJF Project on SourceForge and we want to improve on the Database Access for this framework. Currently, it's semi-flexible, but the access is done at the Task level.

We'd like to setup a simple Interface of some kind that's generic in nature and can host the database access to/from JBJF. Thus, Framework classes don't care what kind of database, they just call a method like getConnection() and a java.sql.Connection object comes back.

I'm wondering what would be better suited, a typical DAO layer with a single Interface or a Plugin type structure where we configure the Database Service in an XML file and the Framework loads the Plugin(s) when it starts up.

tia,

adym

Answer 1

how about abstract all that away and use JPA

Answer 2

It's hard to say without knowing the details, but in general, I would not write my own framework and instead use Hibernate or a similar ORM tool. It already has defined XML for mapping objects to tables and back, can easily swap in/out different database implementations, and generally is a great tool for doing this kind of thing.

Answer 3

The two options you list aren't mutually exclusive; you can have a DAO/Repository layer which you access via some interface/API, while the concrete implementations are injected at runtime to satisfy your dependencies.

For example, write a WidgetRepository interface which defines the widget part of your data access API. You can then provide a FileSystemWidgetRepository, HibernateWidgetRepository, XmlWidgetRepository, JpaWidgetRepository, etc. which implements your interface.

The general rule would be to use as high a level of abstraction as you can while still fulfilling your requirements. In the example list I gave, a JPA-based repository would be the highest level because it abstracts even the ORM framework.

You can then keep a WidgetRepository reference in your objects which make use of it. Code only against this interface. Next, put in place a Dependency Injection framework like Spring, which will inject a concrete WidgetRepository implementation at runtime based on some XML config or auto-wiring mechanism.

Answer 4

I was starting to think that Hibernate had gotten too big and bloated, but I've recently worked on a project using the latest 3.5 release and using JPA and they've definitely slimmed it down and made it much better than some of the other 3.x releases. I'd recommend JPA using Hibernate :-)

One of the great things about this approach is how good Hibernate is at dealing with multiple different database dialects. Our app runs on MySQL, H2, and SQLServer with no modifications (and probably would just run on the other major databases as well).