|
Managed Persistence
BB: What do you think of EJB3?
BT: My most serious criticism was that EJB3 manage persistence at all, and after I wrote the paper "Don't Make me Eat the Elephant Again," they broke persistence out of the EJB3 specification.
I still think that too much is cooked into the behavior that's wrapped around the annotations. The container is much more sophisticated than it has to be. You just have a usage model that makes it easier to program. I much prefer an approach where you have a POJO, not just a programming model that looks like a POJO and wraps the same old EJB2 stuff.
BB: If I'm a developer, why do I care what the container is doing under the hood?
BT: The container under EJB defines the scope of the services that you're allowed to add. With an approach like Spring, it's much easier to add any arbitrary service to a POJO.
For example, I've got this session bean which uses a transaction strategy. I don't necessarily want the JSR 220 persistence underneath it. I ought to be able to use any persistence framework underneath it that I want to use. So this is my criticism of EJB. Persistence frameworks shouldn't be in the scope of enterprise JavaBeans. I'm glad they changed it.
BB: What do you think of container-managed persistence?
BT: Container-managed persistence has been a huge failure. With EJB 1.x, we had remote interfaces without local interfaces. We could not manage relationships in the database. We had to manage them in the model, so joins had to happen in the application instead of the database. In some situations, that was horrible for performance.
In EJB 2.x, we had a whole new set of problems and some of the same old problems. But basically it all comes down to this: you had to know too much to understand how to use EJB with container-managed persistence. It was just too complicated a model. An EJB entity bean, the component, was too different from a POJO. If I wanted to do object relational mapping, I wanted to go all the way from a relational database schema to an object model. But EJB entity beans only got me part of the way there.
BB: What about the ease of learning for Hibernate? Is that a valuable feature?
BT: I like Hibernate a lot. I like it because it provides more leverage and more power through object relational mapping. But if you're trying to use Hibernate to insulate you from the relational database, then you're probably going to get yourself in trouble. That's the case with all object relational frameworks.
BB: Why shouldn't you isolate yourself from the database?
BT: Making the conscious decision to isolate yourself from the work of writing code is different from isolating yourself from understanding the details of the relational database. Hibernate is a tool to give you better programming leverage. You can use Hibernate effectively because you understand what's going on under the covers.
The Complexities of Mapping
BB: You have an object, and you have a relation. They're two different beasts, and the complexities of mapping one to the other often makes people think that this is not the right approach.
BT: Ted Neward and I have had a playful—but spirited—debate on this topic. Ted had a blog comparing the use of object relational mapping to entering Vietnam. You can get yourself into some development scenarios that are tough to get yourself out of.
Some people believe it's perfectly okay to use an object relational mapper to shield you from having to know anything about the database. I think that if you understand what's going on under the covers, then you can use the tools for leverage. They will solve some problems and they will add other complexities.
If you have developers with a good understanding of SQL but not great understanding of Java, then object relational mappers aren't necessarily a good idea.
BB: What kinds of complexities do the tools add?
BT: I have a lot of knobs and levers for performance tuning. How do I gather enough information to use all those knobs and levers? These are very difficult questions but they're solving a difficult problem: how do I look at the database as an object graph instead of as relations?
When I'm doing batch-type operations or when I'm doing reporting, I'm using relational constructs. The use of relational constructs is a clue that I should be doing something else.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
