What functionality to build into business objects?

What functionality do you think should be built into a persistable business object at ba开发者_开发技巧re minimum?

For example:

• validation
• a way to compare to another object of the same type
• undo capability (the ability to roll-back changes)

---

The functionality dictated by the domain & business.

Read Domain Driven Design.

---

A persistable business object should consist of the following:

• Data
• New
• Save
• Delete
• Serialization
• Deserialization

Often, you'll abstract the functionality to retrieve them into a repository that supports:

• GetByID
• GetAll
• GetByXYZCriteria

You could also wrap this type of functionality into collection classes (e.g. BusinessObjectTypeCollection), however there's a lot of movement towards using the Repository Pattern in Domain Driven Design to provide these type of accessors (e.g. InvoicingRepository.GetAllCustomers, InvoicingRepository.GetAllInvoices).

You could put the business rules in the New, Save, Update, Delete ... but sometimes you could have an external business rules engine that you pass off the objects to.

---

This is just one piece of an answer, but I would say that you need a way to get to all objects with which this object has a relationship. In the beginning you may try to be smart and only include one-way navigability for some relationships, but I have found that this is usually more trouble than it's worth.

All persistent frameworks also include finders, ways to do cascading deletes... sorts....

Once you start modeling, all business objects should know how to manage themselves. Whenever you find another class referring TO your business object too much, it's usually time to push that behavior into the business object itself.

---

Of the three things noted in the question, I would say that validation is the only one that is truly required. The others depend on the overall archetecture of the application.

Also, the business rules should be in the business objects.

Whether an object should do its own serialization is an interesting question. I have had great success in the past by having each object handle its own serialization, but I can also see merit in having a serialization module load and save the business objects just the same way as the GUI writes to and reads from the objects. Then your validation will protect against errors in the database or files too.

I can't think of anything else that is required in general.