I'm new to J2EE and I hear often that business processes should not be put in entity beans. Does this not go against the OO principle of Tell Don't Ask ? Seems to me if you put your business process logic in classes other than where the data resides your entity objects have to expose nearly all there state. Is this a trade off ? Is there some way round this, say by adding wrappers to entity beans ? thanks, D.
I've read that as well; however, I've been using EJBs for a few years and I really disagree with that statement. There is nothing wrong with adding business logic inside of an entity bean as long as the logic deals with protecting the state of that bean and that bean alone. For example, if you have an entity bean that is an Account and that account cannot be overdrawn or perhaps cannot have a balance of less than $25, then inside of the entity bean is where the logic should reside. Perhaps only a manager can close the account or make withdrawals in excess of $1,000, etc. Now, if you have logic that would require that you check with another entity bean for some reason that logic should reside in a Stateless Session Bean because this has to do with process instead of state. One thing that should be adhered to is to make access to all entity beans through a session facade. This allows you to change database configuration behind the scenes and doesn't give away your database layout. The downside is that it creates one extra session bean per each entity bean. I'll tell you, this has come in handy when dealing with entity beans because in our application, sometimes you have to do some processing logic before you can even get the bean! Regards, Paul