I was wondering whether object oriented rules are violated in EJB.
EJB divides beahaviours & properties of an object into two which are known as session & entity beans. But this division of properties & behaviours are violation of Encapsulation. As a matter of fact, EJB forces us to place 'logic' into the session beans and 'data' into entity beans which goes against good OOP design.
What's your opinion on this?
Thanks, ... Chisty
M. M. Islam Chisty<br />Sr. J2EE Engineer<br />M&H Informatics<br />Ph. 8802-7121293<br />Dhaka, Bangladesh
EJB divides beahaviours & properties of an object into two which are known as session & entity beans.
Let�s not make any confusion here. EJB doesn�t tell you how to design your OO model, or how to divide the responsibilities of any particular class within your model. What it says, in a nutshell might be simplified like this: session beans are used to wrap up business logic and entity beans are used to represent persistent information. You might have any number and type of objects in between (as POJO(s)) and you might define the relationship between your classes the way you like it. Let�s think about this as a conceptual model. Finally you might use EJB components to make your application J2EE compatible using enterprise beans and let�s think about this like the physical model. The way you map your classes from your conceptual model to your physical model is totally up to you. J2EE doesn�t impose any constraints here.
As a matter of fact, EJB forces us to place 'logic' into the session beans and 'data' into entity beans which goes against good OOP design.
Can you please be more explicit? I mean can you please tell me, which are those good OOP design choices violated here? As a matter of fact I might remember some design patterns that emphasize how to separate the business logic from the data access logic. So please elaborate little bit here, if you don�t mind. Regards.
there's nothing in the EJB model that says that you can't put business logic inside Entity Beans.
In fact a good system design will put 'application-agnostic' business logic inside your entity beans, treating them as first class business objects. By 'application-agnostic' business logic, i mean all of the business logic that is not application-specific, but rather is generic business logic specific to the entity. For instance, if you have a BankAccount entity bean, you should have your calculateInterest() method on this entity bean (not on some session bean), so that the interest calculation business logic can be re-used by multiple banking applications that want to use that particular entity.
If you design your system this way, with entity beans containing re-usable, 'application-generic' business logic, and session beans containing only application-specific business logic, you'll get a much more flexible, maintainable application, enabling more reuse for future extensions and other applications.
This architecture also applies to more lightweight persistent approaches such as JDO of course - the business domain model is implemented with POJOs rather than entity beans, and the POJO business objects implement domain-object-specific bahaviour. Again - for example, your BankAccount POJO has it's calculateInterest() method.
Dave Clark<br />Senior WebSphere Architect<br /><a href="http://www.versant.com" target="_blank" rel="nofollow">Versant Open Access - JDO2 & EJB3</a>