Databases Reference
In-Depth Information
Implementing business rules as
context
methods works well with simple entity models
where the amount of business logic is small. As the size and complexity of the model
grows, the number of business rule methods reaches the point where maintaining them in
a single class becomes problematic. When that happens, you can start extracting methods
into separate classes to group them by entity type to which they apply (
table modules
) or
business process they implement (
services
). However, it is best to avoid making this design
decision too early in the development of the application. Without having a solid under-
standing of the business domain and required functionality, the premature architecural
decisions are often wrong and lead to unnecessary complexity and increased cost.
As a form of business logic, validation rules are susceptible to many of the same potential
problems. As the number of validation rules increases, complexity of the code grows
rapidly and, if you are not careful, can have a significant impact on performance of the
application as well as your ability to maintain it. Just like with the business logic in
general, it helps to keep the validation rules simple and well encapsulated.
To help understand validation rules, they can be separated in two large categories:
.
Persistence validation
.
Transition validation
Rules in the
persistence
category determine conditions that an entity must meet to be
successfully saved in the database. Most often, validation rules in this category apply to
properties entered directly by the users of the application. For instance, a shipping address
(
ShipAddress
,
ShipCity
,
ShipRegion
, and other properties) is required for an Order to be
accepted by the Northwind Traders.
Transition
rules, on the other hand, determine conditions that allow an entity to change
from one state to another. For instance, if the Northwind Traders Company requires
customers to pre-pay their orders, an Order entity must have
OrderStatus
of Paid before it
can change to
Fulfilled
. The
OrderStatus
property is different from the other properties
of the Order entity in that it determines its current
state
.
Entity states might not only have different transition rules; they often have different
persistence rules as well. For instance, when saving an Order in
Submitted
state, you may
want to validate that you have enough Products in stock for all items in the order;
however, this rule does not apply to
Fulfilled
orders because you might keep them in
your system for years after the boxes have left the warehouse.
