Perhaps you should clarify what it is about EJB that you think violates OOAD? Certainly the component model that EJB uses enforces some limits on the design choices that are typically available in writing a normal Java class, is this what you're referring to?
Joined: Aug 20, 2001
Yes, for instance, in normal OOAD we would have a Order class and we will have Order.getPrice() to get the total price for the order. But in EJB, we will have a Entity Bean Order to store all the order related data and then maybe a OrderHandler session bean to actually go and calculate the price for the order, am I right?
You are right in what you are saying, and there have been a fair few discussions on the subject in the past. One of the main arguments is that you are separating data from the functionality that operates on that data, hence breaking the rules of encapsulation. It all depends on how you partition the functionality to be honest. From a reusability perspective though, splitting out the business process logic from the data representation does make sense from a component-based development perspective since you can reuse the data representation components throughout your enterprise. After all, you are more likely to be able to reuse this over the business logic. I think that there are some threads on www.theserverside.com that discuss this at length. Anybody have any other thoughts? Simon