Chapter 9: Understanding Server-Side Business Rules

Overview

This book has covered many major concepts up to this point. You have learned how to create business rules, respond to business rules, create special types of errors to report that your business rules have been broken, and package your code to be reusable. The last major concept you need to learn is the difference between client-side and server-side business rules. In a Windows application this is much more important than in a Web application. The reason for this is that almost everything in a Web application is checked on the server because that is the only place that real intelligence exists in a Web application. To be sure, you can check some rules on the client-side in a Web application, and ASP.NET certainly makes that 10 times easier than it was using ASP, but this idea holds true in most Web applications.

So, why check business rules in two places? Isn't this more work for the developer and a distribution of the business rules to boot? Yes, there is more work for the developer (although mostly in the area of copy and paste), and, yes, it does tend to distribute the business rules. However, you can separate business rules into two categories. The first is database constraint rules, and the second is rules based on the needs of the business. To answer the first question, you are checking rules in two places to reduce the load on the server. You would not want someone submitting a record to be saved if there was absolutely no possibility of that record being allowed in the database. It would be a waste of server time and might adversely impact the performance of the application in a large-scale environment. There is no hard-and-fast rule on what to check on the client side, and it is completely up to the software architect to break up these rules. The rules that get checked on the server side do have a hard-and-fast rule. The server-side rules that must be checked are any rules checked on the client-side plus any additional business rules that need to be checked. You have seen how to check rules, and that has not really changed on the server side, but reporting those rules is slightly different. In this chapter you will see how to report server-side rule violations back to the user interface. You will also see, for the first time, how to handle saving and deleting data in join tables. In addition, you will display and save image information in a SQL Server image data type from a picture box.

The Importance of Business Rules

In the course of creating enterprise business applications, first as a developer and then as an architect, I have always been amazed at the complexity and variety of business rules (and sometimes just how commonsense they are). The one thing you must always remember is that the business rules are everything. If data violates business rules, then it is bad data. Many times people do not like to acknowledge that there is bad data in their legacy or, even worse, in their modern systems.

One company that I worked for had a new system (less than two years old) that scheduled and monitored rail car shipments. This system also reported information about trip times. My first job there was to analyze this data so that the company could purchase or dispose of railcars so that they would be able to deliver product more efficiently. As I began to analyze the data, I found out that about one-third of the railcar shipment times were negative numbers. Apparently these railcars were traveling faster than the speed of light! In other cases, railcars that were part of the same train arrived at the same destination at different times. Huh? And, when I reported these findings to my supervisor, I was told to remove them from my equations or take the absolute value. This was the equivalent of dumping more than 36,000 shipment records to make the numbers look good to someone's supervisor. Needless to say, if the programmers who were responsible for creating the railcar-tracking program in the first place knew how to implement business rules, none of this would have been necessary.

From this short example, you can see just what kind of a disaster was brewing at this company because of the lack of business rules. In another application that I am working on (at the time of this writing), we are converting records from a legacy mainframe application to a new SQL Server/VB .NET application. In examining the data we have discovered that airplanes were sold in 100 and 101 A.D. In addition, maintenance parts for these airplanes were sold around the same time. Common sense would have been to put in a business rule that said an airplane could not be sold until at least after the Wright brothers flew! The data was easy to correct, but the mistake was avoidable with basic commonsense business rules.