Implementing Business Logic - ASP.NET Dynamic Data - page 308

. Stored procedures persist changes to the database, unlike the business rule methods,
which typically modify entity objects in memory and assume that the SaveChanges
method of the ObjectContext will be called separately.
. Stored procedures bypass any validation or business rules you implemented in entity
classes, executing only those implemented in the stored procedure itself or in the
database triggers. For instance, the RangeAttribute applied to the UnitsInStock
property of the Product entity class to prevent negative values is ignored.
. Stored procedures ignore state of any entities that were modified in the object
context but not saved to the database yet. For instance, the code calling the
FulfillOrder method might have changed status of the order to Paid, but in the data-
base it is still stored as Submitted, causing an error in the stored procedure.
. Stored procedures don't automatically refresh entities in the object context. For
instance, the FulfillOrder stored procedure might have changed the UnitsInStock in
a particular row in the Products table in the database, but the entity object that repre-
sents this row in the application code remains the same, which could lead to opti-
mistic concurrency errors later.
In web applications, where ObjectContext instances are created and destroyed for each
incoming request, you might be able to accept the risk of having these side effects.
However, they present a significant problem in desktop and console applications, where
ObjectContext instances can have a longer life span. If other types of applications reuse
your business logic layer, such as the DataModel assembly in this topic's sample, you need
to consider the decision to implement business rules as stored procedures very carefully. In
many instances, the problems caused by the side effects and overhead of the workarounds
you might be forced to implement are not worth the performance improvement you gain
by using stored procedures in the first place.
Summary
O/R mapping frameworks, such as the Entity Framework and LINQ to SQL, provide a solid
foundation for implementing business logic in your applications. Although good entity
design requires solid understanding of both object-oriented and relational design princi-
ples, it allows you to create classes that represent real-world entities from your business
domain and their interaction rules. Encapsulation of entities and rules in the business
layer of the application is essential in Dynamic Data applications that can generate
significant portions of the user interface dynamically and cannot have the business logic
embedded in the presentation layer.
Although your first choice in implementing business rules should be application code,
I/O-bound logic can be optimized to work at the database level. The database servers
already validate uniqueness and referential integrity; custom validation and business rules
can be implemented in database triggers and stored procedures as well. With a small
upfront investment in integration of database error handling, this optimization can be
done as needed without affecting the rest of the application.