What are the disadvantages of having my business logic in my entity beans. I understand entity beans are not meant for that, but i want to know the actual effects of having business logic in entity
"Entity beans are just like plugins,It containes code for persistence of data.Entity beans are ments for persistence only.The main criteria to create them is for reusability.Busiiness logic varies from user to user.So bussiness logic wriiten by onw user can't be used by other user.An it losses it use and uneccesary load also.So it is not suggestable to write bussiness logc in entity beans"
How does business logic change from user to user? Maybe different roles in the system may have slightly different logic but not from user to user. If you had different business logic for every user then your system would break down.
Anyway back to the point. Putting business logic in the Entity bean is a source of debate.
Many people beleive that J2EE has lost the pure O.O. way of having each Class completely define a type of Object. By this I mean an Objects attributes and behavour. This would mean if you use entity beans to model your business components then yes they would have business logic in them.
Others beleive that if business logic that crosses multiple business domains (email, account management) exist then it belongs in a Service Layer (Session Facade). This generally can be thought of as design by use case approach and often ends up with the Entity Beans being nothing than a persistence layer.
Each design has its valid points and I would check out some pattern books for more info.
Lets say you have a Database for another system and some of the tables are same as of your current system . Biggest advantage is that you can reuse the set of entity beans as is, what you wrote for the earlier system and you don't have to write them again. This is only possible if the entity bean had no business logic tied within them else they will not be reusable
"Lets say you have a Database for another system and some of the tables are same as of your current system ."
Did you read this from a book? Database schema's even for very common functionality like account management tend to change from system to system.
Yes i read that from a book long time back when i was trying to gather some EJB patterns. Actually speaking i have had circumstances where within one organisation 2 systems have had about 2 big tables being the same .
Sorry I think basing such a major design decision on if you may come across a table that requires the same persistent mapping is not a valid enough argument.
If you want to re-use the persistent maapping then remove the business methods off the entity beans for the new system.
There are no real dis-advantages of businesss logic in entity beans. Instead it helps to create object view of entity. Only thing is the logic should be really tied to the persistance layer and clients need not know about existance of such a logic.