This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Business objects are objects that concentrate all the logic of your application. That is, instead of putting the logic in session beans, you put them in POJOs, and all the infrastructure stuff is controlled in façades, which are session beans.
Well champ, that's why we would be interested in using an application server, because of the infrastructure it provides. Things like transactions, security, and so on.
In the EJB2.x reality, one of the approaches is to create a model of objects with entity beans, but this concept was over after EJB 3.0. The other approach (which is used today) is to create an object model with POJOs. Ideally, a domain model should not have any infrastructure-related information (i.e. JPA annotations), but that's what most people do. Keeping your domain model pure will increase its reuse, because you'll be able to use it with any framework you want, and thus you won't be tied to any particular framework.
Joined: Oct 13, 2010
Thanks Robert. Got your point. As long as i am keeping my persistence layer separate, I can have the re usability.
What was the difference between Domain Logic and business logic. Is that domain logic deals with respect to entities like how they can be persisted and fetched and business logic refers to manipulation of this domain objects.
The term "domain object" is an academic way of saying "business object."
The term "business object" is a commercial way of saying "domain object."
In other words the adjectives "domain" and "business" mean the same thing and are used in different contexts. If we were building an object-oriented system in a research laboratory at a University, we might use the term "domain objects." If we were building an object-oriented system at a commercial bank, we might use the term "business objects."