CODEWITHSUNDEEP
javadatabaseorm
lcguida
lcguida

Reputation: 3847

Database Layer non-ORM (Java)

I want to write Java code to work with a database, no matter which database is used. My problem is that it wouldn't be Object related. There are some insertions and queries that are but most of them aren't.

Right now we are using Postgresql and pure JDBC, but we may have to make it work with Oracle.

Can Hibernate (which I've never used) solve my problem or should I go for something else ?

Upvotes: 2

Views: 1258

Answers (5)

Lukas Eder
Lukas Eder

Reputation: 220902

I have created jOOQ precisely for that. jOOQ models SQL itself as a domain-specific language in Java. It embraces using standard and vendor-specific features, such as built-in functions, window functions, stored procedures, hierarchical queries, etc. Whenever possible, a vendor-specific functionality from one database is simulated for other databases. That way, most of jOOQ-generated SQL is compatible with any of its 13 supported databases.

See also this related question here:

ORM frameworks used for insert only / query only apps

Upvotes: 3

Gray
Gray

Reputation: 116878

I like @unludo's JPA answer but I thought I'd add some additional details.

I would recommend changing your code to use persistance interface that you define. 

  public interface DataPersister {
     public void saveFoo(Foo foo);
     public void findFooById(int id);
     ...
  }

Your first implementation of the interface would then be using JDBC/Postgresql. If you want to use JPA under the covers then fine. Or if you want to switch to some no-SQL database or even flat files then fine.

Once you have the separation in your own code between the usage of the data and the persistence implementation, then it is significantly easier to switch to a different persister. You can use a cheap database like H2 for testing and switch to Postgresql in production while migrating to a new database in the near future.

Hope this helps.

Upvotes: 3

unludo
unludo

Reputation: 5010

The standard for Java is JPA and it is very powerful. Hibernate is the industry standard as a JPA provider.

JPA helps you write a clean persistence layer. You may write queries which are sure not to break, because they are validated at compilation time. I like to use spring for this, it's so easy to unit test. But CDI now provides the same I believe.

It's also easy to write test classes. As a coworker once teached me, the model is the most important thing you have. You don't want it to break or you have problems.

With JPA you may also generate the schema from the entities, for any database you want to use. From experience, it's also very good.

JPA helps you put good practices at work. That's a lot of value.

Regarding @hvgotcodes answer, yes you have to be careful with the cost but you may also mix jdbc and jpa. That's what Dao's are for.

Upvotes: 1

B. Broto
B. Broto

Reputation: 163

Problems with Hibernate is that you need to modelize your relational database like object model. Sometimes this make difficult working with existing database. So it depends your relational database.

Other framework (not JPA) is Ibatis. Try to look at this framework.

Upvotes: 1

hvgotcodes
hvgotcodes

Reputation: 120198

The problem with writing your own sql is you need to manually optimize it for your RDBMS. Some RDBMS support varying sql constructs.

So you need to balance that against the overhead of switching to an ORM based solution. Or, make sure you sql is 100% standard so you don't use any constructs that work in one RDBMS solution and not in another.

In your particular situation, it's probably going to be easier to just fix your sql than rework your entire persistence layer to use ORM. Sometimes the best tool is the one you know. If your current application doesn't have a concise model layer, switching to ORM is going to require a lot of work. You could of course use hibernate and just use strait sql queries, but what's the point if you are not going to model your data.

Hopefully, all your persistence concerns are in one DAO layer, with lots of integration tests, so you can quickly identify what breaks when you switch RDBMS. If you don't have integration tests that focus on persistence, then now is the time to start writing them.

Upvotes: 0

Related Questions