Business objects are a much overloaded term in today's software development and it can mean many things to different people. When we talk aobut business objects in the context of this toolkit, here's what we are talking about:

Code Abstraction

A business object is an abstaction layer that acts as a collection of operations against an entity model. ORM tools like Linq to SQL or the Entity Framework generate 'Entity Models' that model your application's data and provide the database abstraction to persist that data to the database. While you can easily use the entity model and the database abstraction directly in your top level application code (like a Web App, Web Service, WPF, Windows Forms or Console app), it's generally not a good idea to directly interact with the model's underlying data operations at this level. It makes reuse very difficult and scatters database logic all around your application top level (or UI or Service) code. If you need to fix a task that is used in multiple locations you have to hunt down all of the locations and fix the code in all places.

The model is meant to be pure 'data' - a set of objects that represent only properties with only minimal code associated with it. The minimal code that might be attached to model entities typically is property initialization/setting default values and minimal validation via DataAnnotation Attributes and possibly implementation of validation interfaces like IValidatableObject. Other than that the entities in the model are meant to be pure POCO objects that have no internal logic associated with them.

A business object then acts as the code store that manipulates the model. Where the model is all about properties, the business object is all about methods that manipulate the model. Base business object methods include typical CRUD operations like NewEntity(), Load(), Save(), Delete() and helpers as well as additional methods that deal with validation and repetitive process error handling of updates in the Save() method. Each of these methods are overloadable either directly or via hook methods that provide before and after code hooks that let you perform additional tasks to entities.

A business object serves as common code location with a known base set operations that are supported and can be extended by your code. The idea is rather for your top level code to interact with the model directly, the top level application interacts with the business object and requests data from the business object or asks the business object to perform a specific operation. The application level code never talks directly to the model and the database, but only talks to the business object which in turn talks to the model and performs the actual data operations.

Think of the business object as a container for all the code and logic that is associated with a particular business entity or process.

Common Code Base

The main advantage of a business object is to have a common, known location for all operations that pertain to a particular business entity or process. A business object is a logical abstraction that logically encapsulates a set of common functionality. So if you have an Invoice business object all operations that relate to an invoice and likely also the lineitems associated with the Invoice are handled inside of the Invoice business object. You know where to look if something related to an invoice goes wrong. Having the code in one location makes it easier to find if something does go wrong and it typically also makes it much easier to follow the flow of the code.

Simplified and more focused Code Logic

Further having a business object whose only responsibility is to serve and manipulate data and not deal with the front end data presentation the logic, is often greatly simplified. It's much easier to create small atomic methods that have very focused logic pertaining to one particular task. And finally because business object methods are non-visual they are often much easier to test whether you use full scale unit testing or just manual integration tests.

Code Reuse

Using a business object also promotes reuse - when you create a custom business object method to perform a query or logical operation, that query now becomes available anywhere else in the application from the same single code base. You're not repeating yourself.

Base Functionality - Code you don't have to write

A business object framework should provide some core functionality like basic CRUD operation to Create, Read, Update and Delete data from the database. The business objects provided in this framework provide core CRUD operations with NewEntity(), Load(), Save() and Delete() methods which provide base functionality for these operations that don't require you to write ANY code other than calling these methods. Additionally hooks allow you to extend these methods and provide additional functionality. There's also LoadBase() method that makes it easy to create custom load operations so you can easily create methods like LoadFromInvoiceNumber instead of loading by an Id.

Future Proofing

Because a business object is an abstraction layer you have the possibility in the future to swap out the business object layer with a different underlying database technology. Microsoft is in the habit of obsoleting technology rapidly and having a common business layer makes it possible to insulate the application layer from the underlying database/ORM layer. As an example, we have had a number of LINQ to SQL applications that we were able to migrate to Entity Framework Code First with only minimal code changes. In the process the front end application never had to change at all - the only thing that changed was a small part of the business object's entity layer interaction. While this isn't the most frequent scenario - it's useful to know that you can protect your front end layer at least from backend style changes.

Should you use Business Objects?

Reading through all this you might think that using business objects is just extra overhead that adds complexity to your application. But the reality is that this simple level of abstraction that we've described above adds almost no overhead at all to the performance of an application. All you're really doing with this approach is re-aligning where code is located and how data is returned to your application. The operations performed against the model are still the same as you would with direct data access, except that the logic is moved to a more re-usable and more easily testable and debuggable location.

Using business objects also tends to make you think more about your business process before you start implementing functionality as you have to design your business objects methods before you can use them in the front end. You need to actually define your inputs and outputs clearly and think of them independently of the final application or user interface that needs to represent the data. This will often lead to much cleaner, less complex and more atomic code as a little forethought goes a long way to create more logical data interfaces.

Using the business objects provided in this toolkit is very easy and you get a lot of common functionality for free out of the box. Take a look at the basic getting started guides for each of the tools and dig in - you'll find it's very easy and likely will cut down dramatically on the amount of code you write for basic operations.