Alan Knight posted this in comp.lang.smalltalk:
A comment from another poster:I find writing EJBs to be extraordinarily tedious (as with Java in general), but haven't noticed any serious impediments to development.
Well, some might consider being extraordinarily tedious (and thus slow) to be an impediment to development :-)
As Niall pointed out, there are slides on the web where I covered some of these things in moderate detail. For the high-level view:
- I don't think the domain objects as components view of entity beans is a particularly good thing to try and accomplish. You throw away basic OO concepts like inheritance and polymorphism and don't get much in return.
- You lose testability. You can't test an EJB outside of deploying to its container. This is why, if you look at EJB usage patterns from people concerned about agility, they typically recommend against them. e.g. Martin Fowler's typical pattern is paraphrasable as: Don't use entity beans. You can use session beans, but they should act purely as a facade to an ordinary object with exactly the same API
- I don't buy into the model that the world is divided up into authors, assemblers, deployers, and whatever the fourth one is, especially at the fine-grained level that entity beans imply. You end up doing much more work to deploy a simple object (thus the tedium). You get to write multiple XML descriptors, totally more bytes than your actual object, just to make it work.
- The programming model is both limiting and bizarre. So, e.g. the prohibition on "loopback" forbids any sophisticated object programming techniques like recursion, double-dispatch, or even complex graphs of objects. The "enforcement" of relationships, where setting a value in one place can result in nilling it out in another is a wonderful example of the principle of most astonishment.
- The persistence model is very constraining, and not very powerful. I'll admit I'm fussy about persistence models, but IMHO this one is particularly bad. Compare what you can do with an object database, one of the JDO-relational mappings, or a tool like TOPLink, with what EJB constrains you to. EJB 1.X at least had huge holes in the spec where you could do something useful. EJB 2.0 plugged the holes, but not with anything useful.
- Performance is bad. You're adding multiple layers of code-generated stuff and remote calls onto every operation. We had people measuring performance hundreds of times worse between regular Java objects and EJBs doing the same thing.
I could expand on these, although I might have to start consulting notes if things get very technically detailed. It's been a while.
Heh. The principle of most astonishment. I'll have to remember that one...