What is the difference between business class and domain class? What is meant by persistent classes?
views:
150answers:
5What is the difference between business class and domain class? What is meant by persistent classes?
A "domain" class is one that models your data. It is typically used to map data from your data store (e.g. a database) to an in-memory object. A business class is one that your application works with. It can be the same as the domain class, and usually performs some sort of business logic or processing.
Persistence refers to the ability of the object state to be saved to some data store (e.g. xml, a text file, or more commonly, a database). So the state of this kind of object "persists" whether the application is running or not.
It sounds to me like you're curious about Object/Relational Mapping. I recommend reading this wikipedia article to get started.
Business classes are classes that are designed and used for specific project and hardly reusable to other project.
Domain classes are classes that are designed and used for specific domain which can be used by multiple projects that do similar thing.
For example, JDBC classes are domain classes for Database access. Swing classes are domain classes for GUI construction and manipulation. Form1
which contains a set of component used to display "Hello World" messsage is business class.
The terms Business and Domain are often used synonymously. Personally, I prefer the terms Domain Model, Domain Object, etc. since they aren't constrained to deal with business (whatever that is).
As an example, in Safewhere we work mainly with Claims-based Identity and Authorization. The concepts we model have very little in common with traditional 'business', so in such cases, I think Domain Model is a more appropriate term.
A business class provides domain specific logic.
A domain class is an entity representing part of the domain.
A persistent class, or better, a persistent instance, has the same data after a server reboot (the data is typically stored on a database of some kind).
Let's take a banking transaction as an example. You'd have a persistent domain class Account. My Account (an instance) would have a field saldo with value 1000.
The transaction business logic which handles the debit is something like AccountDebit and has as method debitAccount(Account account, int amount), and as business logic
int saldo = account.getSaldo();
if (saldo < amount) {
throw exception("You're too poor");
}
saldo = saldo - amount;
account.setSaldo(saldo);
account.commit(); // save the values to persistent store
And I do know that money is typically not an int, and that the debitted amount is normally creditted to someone else :)
A domain class is a class from the Domain Model that Martin Fowler describes as follow in Patterns of Enterprise Application Architecture:
An object model of the domain that incorporates both behavior and data.
At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.
And to me, there is no difference with a business class: a business object doesn't perform more or less business logic than a domain object (a domain model where business logic is implemented outside the domain objects is called an Anemic Domain Model, which is a pejorative term), domain objects and business objects are the same thing.
Finally, a persistent class is a class that can be... persisted which means transferring an in memory representation of information to a physical storage that will persist beyond the live of the JVM. Often, persistence is implemented using a database (but this is not the only solution, see for example object prevalence). Typical persistence operations include create, read, update and delete which are known as CRUD operations. Domain objects are very frequently persistent i.e you can perform CRUD operations on them through an API that hides the underlying details of the chosen persistence engine.