email article printer friendly more resources

Enforce Business Rules With .NET
Script for .NET offers new ways to implement business rules in enterprise applications.
by Rob Ericsson

June 2003 Issue

For This Solution: .NET Framework, Script for .NET

All organizations operate according to a set of rules commonly called business rules. Business rules enable organizations to carry out day-to-day business while, at the same time, imposing limits and conditions by defining acceptable behavior in response to specific events. For example, a business rule governing discounts for holding multiple policies with a given insurance company might be: If a customer has two or more automobile policies, give them a 5-percent discount off of their total bill.

When you look to enforce business rules in your .NET applications, integrating Script for the .NET Framework can make your application more flexible in the face of business changes. It can provide a development platform for your business rules while keeping your core code maintainable. The capabilities Script for .NET provides will enable you to keep up with the inevitable business rule changes that are a by-product of today's dynamic competitive and regulatory environments (see the sidebar, "Business Rules Basics" for more information about business rules).

From an information system perspective, business rules define the processes, data, constraints, and performance criteria acceptable within the organization. People rely on information systems to enforce the rules and, when they're implemented properly, information systems do a good job of enforcing them. The real challenge with business rules is to understand them and implement them correctly. There are many books devoted to how best to gather and codify an organization's business rules, so I won't cover that subject in depth here (see Resources). Suffice it to say, producing a proper set of business rules in an information system requires you to analyze the problems and design a solution that expresses that understanding. Ideally, this should be done as closely with the business subject matter experts as possible.

Assess Business Rules Options
You can enforce business rules at a number of levels in a typical application. Many modern line-of-business distributed applications are constructed using a tiered architecture consisting of a number of logical layers. The canonical distributed application consists of a presentation layer, or client, that communicates with the business logic layer, which consists of an application server containing the business logic. The business logic layer communicates with a data services layer that provides data access and storage. You can enforce business rules at any of these layers (see Figure 1).

Figure 1 Layers Upon Layers

At the bottom level, in the data services layer, databases can use constraints, triggers, data types, and stored procedures to enforce business rules in the database. This traditional method of enforcing business rules is still a viable option today. Storing the business rules so close to the data centralizes the rules and maintains data integrity with respect to those rules. However, writing complex rules in a database language such as Transact SQL or PL-SQL is difficult compared to writing the same rules in Visual Basic, C#, or Java. Also, you need to weigh the risk of altering your enterprise data store carefully whenever business rules change. Imagine writing and maintaining stored procedures to enable a one-time promotion. It probably makes the most sense to use the database to store simple and relatively static business rules. For example, if you know that all your customer records must have a customer identifier, using a database constraint to enforce that makes perfect sense.

At the top level, in the presentation layer, a client can enforce a rule programmatically or through user-interface controls when users edit the data. These types of rules can improve system response times dramatically and increase usability by guiding users to enter correct data and avoiding trips to the other layers to correct typing mistakes. However, the presentation layer is no place for complex rules that need frequent updating. Rewriting a user interface for every business rule change is disruptive and costly, especially for a thick client application that requires updates to multiple desktop computers.