ASP.NET 3.5 Enterprise Application Development with Visual Studio® 2008: Problem - Design - Solution

3.1. Problem

This chapter develops a design pattern for static business objects and editable business objects. It also explains where to code validation rules to allow for the flexibility to work with any user interface or database. The distinction between business requirements and validation rules may be confusing because many terms are used interchangeably in different companies. Terms such as user requirements, business requirements, business logic, functional requirements, and usability requirements are just a few.

Think of business requirements as a definition of the business process or workflow. These requirements help define your object model. A business requirement for the example in this book would be "the system must allow for three levels of approval for every request and track the date when the request was approved." That requirement could be designed it two different ways. One way would be to have three different approval properties called first, second, and third, which store the date the request was approved. A second way would be to create an array of approvals on a request object, which store the level and date of approval. This is totally up to you; the goal is to meet the business requirement.

Validation rules are for data integrity checks such as required or unique fields. These rules are still defined as business requirements by the user but they don't affect the object model. For example, another requirement is "the user's name is required and must be unique." ...