A blog discussion has started on the subject of lightweight containers, and somehow changed to OR mappers at the end :)
Neward on Crupi
What is the state of the enterprise Java world, anyway?
I think there are some KEY differences with the recent move to lightweight containers.
The various tools that I seem to prefer these days have one thing in common:
Transparency
I think this is a huge thing. I think that so many projects have gotten away from core OO practices (and OO doesn't mean distributed objects Ted!) because they were stuck with crappy EJBs. These applications were built using "patterns" of:
Stateless Session Bean - Entity Beans - which use DTOs
This isn't OO. This is RPC. The entity beans often had simple mapping, and don't allow for inheritence. DTOs are evil as they are a duplicate layer of structs that you are throwing around.
Note that I am talking about an application that isn't a service. I am talking about building an internal application first, using good OO practices, and THEN you can lay on the service layer to allow for external stuff.
So, back to transparency.
IoC Containers
I can finally write code that is just POJO based. There are no extension points to the framework. I am not stuck extended evil EJB interfaces and classes, having to create "home" interfaces and such. This all gets in the way. Not only does it get in the way but not I am totally tied up in knots.
With a container like Spring you look at my code and would have no idea if I am using it! What if I want to move to something else like Pico or Hivemind? I can. My core business logic is in tact and I can go about my way of moving. I don't sit around crying because I have to munge my logic from the coupling with the framework! I love it.
JDO, Hibernate, etc
I like transparent persistence (not that it is truly transparent due to the OO-DB mismatch... but it gets close). Once again, I can develop a full, rich, domain object model. The model can even have inheritence and interfaces, and maybe people will put in real business methods that do things instead of just gets and sets (gasp!).
Now with a marriage of these technologies I have a clean domain object model (transparent persistence), and clean services (lightweight container). Testing IS a lot nicer too in my experience Ted. You don't need to run around finding or building bloody mocks for the environment.
2PC
I do agree with Ted in that EJB is good for some things, such as 2PC and Message Driven Beans. There is going to be a kick arse way to do MDB in Spring coming up soon, so that need will go away. What about 2PC?
Well, a couple of things can happen:
a) The lightweight container can support them
b) You use an EJB when you need to do 2PC! One nice thing about the lightweight containers is that they can be used WITH EJB too :) However, HOW many applications need 2PC? 2%? And then within those applications, how many of their transactions need to be 2PC?
If you can't see that Spring isn't nicer than EJB? Ouch. You must like eating the elephant ;)
Previous Topic
