Professional UML with Visual Studio. NET. Unmasking Visio for Enterprise Architects

A business object is an object usually representing a real-world person, place, or thing. Business objects allow you to represent both the attributes and behavior of these entities. For example, if you are creating a point-of-sale invoicing application, you may have business objects representing real-world entities such as a customer, an invoice, a payment, an inventory item, and so on. Business objects allow you to create a one-to-one correspondence between real-world entities and objects in your computer system.

Object Modeling Compared to Data Modeling

If you're familiar with data modeling, this concept of modeling entities shouldn't be too foreign. As shown in the following image, when you model data, you often create data tables representing attributes of real-world entities. Using the point-of-sale invoicing application as an example, you may have customer, invoice, payment, and inventory tables that represent real-world entities.

During data modeling, you design tables with fields that represent the properties or attributes of real-world entities. For example, a customer table may have fields for a customer's name, mailing address, e-mail address, phone number, and so on. An inventory table represents the properties of a real-world inventory by means of description, quantity-on-hand, price, and other fields.

However, modeling the attributes of a real-world entity is only half the story. Entities also have behavior that can be modeled. For example, customers can change phone numbers, buy loads of inventory and become 'preferred' customers, or not pay their bills and be put on credit hold. Inventory can be sold, ordered, back ordered, and change in price. Business objects allow you to encapsulate both the attributes and behavior of real-world entities.

Modeling Attributes and Behavior

Business objects model the attributes of real-world entities because they encapsulate an entity's data. As shown in the following image, all data manipulation in your application should take place via business objects. This image shows a user interface, possibly a Windows Forms client accessing application data using business objects. The Customer Business Object accesses the Customer data, the Inventory Business Object manipulates the Inventory data, and the Payment Business Object manipulates the Payment data.

You can add data manipulation methods to your business object classes. For example, a Customer business object might have a method called GetCustomerByPk that accepts a customer primary key value and returns a DataSet containing the specified customer. An Inventory object might have a method called GetInventoryByPartNumber that accepts a part number and returns a DataSet containing the specified part. You can also add methods to your business objects that manipulate and save data to the back-end database.

Business objects model the behavior of real-world entities because you can add methods to them representing real-world actions. For example, you can create a PutOnCreditHold method for a Customer business object that performs a series of actions to put a customer on hold. When you want to place a customer on credit hold, you simply call this method. You can add a ChangePrice method to an Inventory object that you call (passing a part number and the new price) whenever an inventory item's price changes. Later in this chapter, we'll be taking a closer look at how to decide which methods should be added to a business object.

Building Monolithic Applications

As mentioned earlier, the alternative to using business objects is creating monolithic applications. Many software applications are still created this way today. Sometimes the reason that they are created this way is that developers believe it's easier - and on some levels, it is! In other cases, upper management may not be willing to make an investment in analysis and design. Regardless of the reason, monolithic applications are extremely inflexible. Whenever change comes along, and it always does, you have to spend countless hours tearing out code (and your hair!) to implement new technology.

Building Component-Based Applications

There are many benefits from building component-based applications with business objects, which we'll cover in the next section. As you realize these benefits over time, you will begin to understand why we can say with confidence that you will never go back again to building monolithic applications.