“What naming standards did you use? I can try and reinvent the wheel but why do that if you have already tackled this problem.”

I don’t necessarily know that *my* naming standards are the best - the important thing is to standardize on something. Some sample rules I like:

1. Use descriptive, intuitive names for things - even if the database doesn’t.
2. Entities should be singular, OneToMany relationships plural.
3. No underscores, no redundant names (ie, if the entity is Course, don’t name the description field courseDescription, just call it description).

“Do you have an example when it would be better to use stored procedures?”

When to use stored procs or functions will depend largely on your application and your database. I’ve worked on fairly large applications that never needed to use stored procs, or only used 1 or 2. If you need to operate on a lot of records at once, or use a lot of records to calculate something, stored procs can come in handy.

For example - One part of one application I worked on had to do with training. I needed to figure out how many people were scheduled for a course at a particular facility at a given date. Unfortunately, there were a lot of peculiarities in the data, so this couldn’t be accomplished with a straightforward query, and it would have involved pulling back thousands of records from the database. In cases like this, a proc or a function will always be faster - sometimes significantly so.

“What is a rich model exactly?”

Several years ago, you started seeing trends with Hibernate and with EJB entities where your model objects would be containers of data and nothing else - no behavior. Rich domain modeling, in this context at least, entails adding behavior to your object.

Simple example - Let’s say you have a Course object, representing a training course, and a name is generated for it based off attributes for that particular Course. With anemic domain modeling we’ve seen in the past, that code would go in a service layer object. With rich domain modeling, that logic goes in the model class. The benefit is that it is more reusable, easier to refactor, and better organized to have it in the model class itself.

“How did you decide whether to use JPA or native Hibernate? I understand JPA offers a subset of the Hibernate functionality so what did you decide on and why did you make that decision?”

Well, keep in mind that if you use Hibernate’s JPA implementation, you aren’t necessarily forgoing extra Hibernate functionality - you can still use Hibernate specific functionality wherever you need it. Going with the JPA standard makes it easier to upgrade (and potentially change implementations) in the future.

“We are very much for the DRY principle but how do you decide whether to leave the Oracle constraint in the database or migrate the logic to the Entity?”

I think it is generally a good practice to have the validation rules in both places, even though it is a bit of duplication. I mean, what happens if you have stored procs hitting that same data? Or you have to write native SQL in some spots? Or if other projects end up hitting the same DB?

I hope those answers help.

- Spencer

Very good article. I have a few questions I want to ask but I could not find an email for you so I thought I would post them here and you can respond directly to me if you prefer.

I am working on adding a JPA/Hibernate layer to an existing database. The current system is simply two tier, Oracle and JSP. It makes use of a lot of stored procedures and the data set is massive and the structure is very much de-normalized.

2) Use (and enforce) good naming standards from the beginning.

What naming standards did you use? I can try and reinvent the wheel but why do that if you have already tackled this problem.

4) Let the database do the things it is good at.

very good example of when to let the database do the hard work. I am trying to avoid using stored procedures et al and so far it is working but we have not looked at performance issues. Do you have an example when it would be better to use stored procedures? The application we are using will have to load and update 100,000s rows at a time so i am wondering if letting Hibernate handle that is a good thing. If not do you have an example of doing this in a better way. I guess I am looking for more complicated examples.

10) Use rich domain modeling.

What is a rich model exactly? I have been surfing the web trying to find useful examples but all i am finding is really simple examples that don’t really help unless you are trying to build a really simple book store ;-) . I have seen lots written about domain driven design and the use of POJO’s and we are trying to use these patterns as much as possible but we feel we have not really grasped the concepts. Do you have an example of a class hierarchy or collaborators that make use of a rich model and that don’t. A before and after comparison would be much appreciated.

A few more questions not directly related to your article but you may have tackled these as well:

a) How did you decide whether to use JPA or native Hibernate? I understand JPA offers a subset of the Hibernate functionality so what did you decide on and why did you make that decision?

b) We have lots of business logic in the database in the form of Oracle constraints and many stored procedures. We are very much for the DRY principle but how do you decide whether to leave the Oracle constraint in the database or migrate the logic to the Entity? I guess it may depend on who else uses the database but assuming we are (or will be) the sole users of the database, does removing the constraints leave the database naked in that the data is there but the logic governing the structures is elsewhere? How about if we want to to use .NET apps say and Java apps where we can’t necessarily share the entities, where should this business logic be stored?

I know I have asked a lot of question but I am hoping you can shed some light on your experience.

Many thanks in advance.

Eric

:-)