I am appalled at the general quality of J2EE applications I have seen over the past few years as a consultant on various sites. Time and time again I have seen 'J2EE design patterns' utterly misunderstood and confused.
What proportion of J2EE projects make the following pitiful errors:
- EJBS that do nothing but act as delegates to DAOs and demarkate database transactions. They contain not a whiff of business logic, which is usually found in the database.
- So called 'Data Access Objects' that utterly fail to implement the DAO design pattern by not encapsulating the underlying persistence solution from the objects clients.
- Catching checked exceptions and then... throwing them away. If you're really lucky, the code will replace them with a meaningless new MyCrappyApplicationException("general error") type of thing.
In my experience, these things are very commonplace indeed, and once implemented, very difficult to resolve. There is a serious problem in the IT industry with developer skill levels.
Catching checked exceptions and then... throwing them away. If you're really lucky, the code will replace them with a meaningless new MyCrappyApplicationException("general error") type of thing.
If you're really lucky, they'll re-throw them :-)
I usually have a delegate on the client which mirrors the EJB but catches RemoteException (checked) and rethrows as Runtime so the clients don't need to bother about it.
What would be a better way of getting rid of the RemoteException which no one can deal with anyway?
The other thing to bear in mind is political pressure. Too many times I have gone into a project that "must use EJB" but also mandates that "business logic must be in POJOs", so indeed you end up with an EJB simply acting as a remote view of the POJOs. Again, what is a better solution *for thick clients*? Hessian/burlap etc. just aren't as attractive at a corporate level.
Remember, there is a big difference between co located J2EE web apps and J2EE apps with client side apps.
Your first gripe is actually a legitimate design pattern for EJBs. To facilitate unit testing of your business logic outside the EJB container, many folks DO put their business domain logic into POJOs and wrap them with EJBs for the value-add services they provide (declarative security, transactions, instance management, etc.). There's nothing really wrong with that. In fact, if your business logic is written this way, it's much easier to port your application to a non-EJB server in the future and use some sort of IoC container (like HiveMind or Spring) to provide the value-add services.
On the other hand, I would agree with you on the last two points you make. I've seen a lot of that too and it's pretty scary.