When using Hibernate ORM should i model first a class diagram or DB diagram?

i'm fairly new to Java and Hibernate. At work we are developing a medium sized, formprocessing J2EE web application using Spring, Hibernate, JBOSS and so on. What is 开发者_开发知识库the correct approach using Hibernate? Should i create first a class diagram and the map it using hibernate to DB Tables or should i first model the DB Tables and then map it to Hibernate Entities? Or does it depend? If it depends than on what? Has either of this approaches drawbacks against the other? Is it possible to map "any" class diagram to a DB using Hibernate 4?

Both approaches are correct, but used in different situations.

1. When creating a new application (new model) ir is ussual to create the entities first and let hibernate/JPA to create the tables. It is more simple and will probably generate better object model (since you are creating it directly). But you still have to have in mind, that you are creating DB tables to, so you should think also about DB normalization etc.
2. You will use the approach with tables first, when mapping some legacy schema, where you have no choice but to do it. The object model might be a little clumsy...

But I repeat, both approaches are valid, if you are more DB engineer than Java programmer, you wold probably do 2) because it might be more natural to you. I as a Java programmar do (almost) always 1)...

You can the same results with both approaches and in both you have to think about, what will hibernate generate for you...

It doesn't make any difference: either is mappable to the other, but you need to be aware of both (the ORM impedance mis-match).

If you're doing greenfield development, IMO, go from class diagram => DB tables; it's easier to think in classes. In general, rational class structures map nicely to DB tables, but keep efficiency in mind (the "be aware" part).

I think it's very important to clearly identify your entities and the relationship between them, as they're your representation in Java-world of the real problem in the domain world. Make sure your entities have a correspondent in business terms. In fact, that's a whole problem in itself, with several approaches (DDD for instance). Once the entities are clearly defined, you should also consider what's the main purpose of your application. You can map it differently with hibernate based on that.

For instance, a persistence layer that's optimized for reading can make use of a less normalized DB design, where a bit of redundancy might give you extra speed. In Hibernate terms, this means selecting an appropriate Hiberante inheritance mapping for your hierarchy of objects (assuming you have one) or maybe relying on fetch-joins for bulk reading. Lazy-loading collections can also help, but again, this is something that can be done after you've defined your entities.

Another thing that's important I think to identify is which entities are the aggregate ones, in other words which are the ones having a clear identity, lifecycle of their own, which translates to which entities you'd explicitly query for. The other ones (their dependencies) would generally be managed via cascading the operations.

Keep the relationships between entities simple, avoid bi-directional relationships if possible.

Not sure if this post is actually what you need though - bottom line would be, at least for a beginner, start with classes, keep it simple (uni-directional) and make sure you're not mapping things with no business meaning unless you really-really have to!

I have to disagree with the other answers, you should strive to embrace the database model first approach in general (although there might be particular trivial cases where the object model first approach is better).

The relational model has succeeded the networked model (OO, graph databases) and the hierarchical model (JSON, XML) a long time ago, providing advantages over the other data representations, even if the models can technically be transformed into one another. In the long run, it is much easier to evolve a well designed, normalised schema using your database vendor's DDL rather than figuring out how to generate DDL and update statements from your OO model increments.

In my opinion, your client model is just a derived version of your database model, and it does not fully represent your entire domain. Instead, your database and data access layer are a subsystem of your entire system. And within that subsystem, the relational model should be king. Derived entities should be... derived, e.g. by using a code generator.

I have blogged about this in more detail here.