This article on ‘Component Inheritance in EJB2.0’ on the java.net site attempts to give an explanation and make excuses for why the EJB2.0 spec is so fatally flawed. This is an interesting article because of the spin that the author takes – it almost sounds like he is making excuses for the flaws in the EJB2.0 spec and to justify why it is actually ok.
The author makes a statement that the reason why Entity Beans do not have inheritance is because they are misunderstood and are actually ‘componenents’ and not objects. Well a component can be different things to many people, but an Entity Bean as a component is a very fine grained component if you ask me. The author states that therefore it is ok that Entity Beans do not inheritance because a component does not represent state of an object.
This is nonsense. An EntityBean is intended to represent an Entity in a system. An Entity, as an Object, has State and Behavior. When I model my application, I identify types and subtypes and the relationships between these types and implement them as Classes. The reason why (one of the reasons why) EntityBeans are flawed is that I cannot implement EntiyBeans to represent the data model that I have jsut described – this type of data model is natural to implementing an Object Oriented system using an Object Oriented language such as Java. To have a persistence mechanism that does not support features which are core to the language I am using to implement my system is just nonsense. This is the main reason why the EntityBean part of the EJB2.x spec is flawed.
The POJO approach in Hibernate (and other ORM tools) is the correct approach in my opinion, and the reason why this approach has now been adopted for the EJB3.0 spec moving forward. Don’t make excuses for why EJB2.x is wrong; accept that it is wrong and move on – there are better solutions out there.