Chapter 5: Building Business Objects

While building business applications and overseeing the development of them, I have seen many applications go awry because of the poor construction of the business objects. The rules that the business objects are supposed to implement are not implemented correctly, the rules are implemented in the user interface, or the rules are implemented solely in the database. Each of these three issues has brought more than one system to its knees. I have seen application development cancelled during construction, and I have seen applications scrapped after the construction was complete because of a failure of the business objects. When most of us think of an application, we think about the data the application accesses and the user interface through which the user enters and views information. The truth of the matter is this: These are not the application. The database is a repository for information; it does not do a lot of processing (in some cases, none at all, which is not necessarily right either). The user interface is a window to the data. In a perfect world, the user interface does not do any processing except display the information. The business logic, which is the application, should perform the bulk of the processing of information.

This chapter concentrates on building business objects in such a way that they can verify business rules and report useful information to the user. There are many parts to this process; it is not a cut-and-dried process. However, once you have implemented the business rules correctly, you can reuse the majority of the code with only slight modifications. The .NET Framework provides some mechanisms to help you trap and report errors—no matter what the user interface is. You will start by going back and modifying your code that retrieves Regions because it is a small block of code and it will be easy to understand. Then you will move on to building the Employee business objects where you will see more complicated rule processing.

Exploring Business Rule Types

There are two types of business errors: One is a constraint error, which generally controls the size and type of the data so that it can actually fit into the database, and the second type of error is a business rule. Database constraint errors generally consist of the appropriate data type and the length of that data type. For example, you cannot put a string into a numeric column; or, if a field is defined as a varchar(10), you could not insert a value with more than 10 characters. A business rule is something along the following lines: An employee is set to receive a raise and the business has put a rule in place that a pay raise cannot be more than 7 percent at a time. The user entering the pay raise percentage accidentally enters 9 percent. The application should capture this and return it to the user as an error. Another example of a business rule may not seem so obvious—the format of data, such as an e-mail address. A business rule might require that the e-mail address is in a valid format. This is something that is difficult, if not impossible, to verify in a database and has nothing to do with data types or lengths.