Databases Reference
In-Depth Information
A simple rule of thumb to decide which type of exception a business rule method should
throw is to think about who is responsible for solving the problem. If the error is caused by
something the
user
did and needs to correct
in the application,
throw a
ValidationException
.
If the error is caused by something a
developer
did and needs to correct
in the code
calling the
business rule method, throw an
InvalidOperationException
or an
ArgumentException
, if
the error is associated with a specific method parameter.
NOTE
Tr ying to design a comprehensive set of validation checks to a business r ule method
upfront is not only challenging, but also counterproductive as it often leads to analysis
paralysis and over-engineering. Instead, it is normal and desirable to add validation
checks to the business rule methods as you continue to learn the business domain
and discover new error conditions your application needs to handle gracefully. As long
as you continue to create new and maintain existing automated tests that cover most
of the business logic in your Entity Framework context and entity classes, the risk of
introducing breaking changes remains low throughout the lifetime of your project.
Implement State-Specific Persistence Validation in Separate Validation Methods
When persistence validation rules differ significantly between entity states, you can
simplify implementation of the validation logic by creating a separate validation method
for each distinct entity state. As an example, consider validation rules for the Order
entity.
When the
OrderStatus
is
Draft
, the Order entity object represents a shopping cart of a
customer shopping on the Northwind Trader's website. A draft order might be empty; it
does not have to have a shipping address or an order date, but for the sake of this
example, let's say that a draft order needs to be associated with a customer because that is
how the system retrieves the shopping cart for returning users.
On the other hand, when the
OrderStatus
is
Submitted
, the system has to ensure that
OrderDate
,
RequiredDate
, and other properties are valid, as well as check that all items in
the order have a sufficient number of units in stock. These validation rules are simply not
applicable to orders in other states. In particular, for draft orders, you don't care if the
items are in stock because you don't know how many items the customer is going to
order. On the other hand, for fulfilled orders, the items have already been shipped from
the warehouse, and it doesn't make sense to check the current inventory.
Because the declarative validation framework in the
DataAnnotations
namespace does not
support conditional validation, you need to implement state-specific validation rules in
validation methods. Although you could create a separate custom validation method for
each property, many validation rules apply only to a given entity state, so the same condi-
tional logic will be repeated in multiple validation methods. To reduce code duplication,
group validation rules in a smaller number of
state-specific
methods.
Listing 9.1 shows an example of implementing state-specific validation rules for the Order
entity. In this implementation, the
Order
class has a separate validation method for each
