0

I have an eCommerce website and I like my projects very n-Tier/Loosely Coupled/highly extensible.

This project is in MVC 3, a Domain Library, a Service Library, and a Data Access Library (repository pattern).

However, I'm cautious as to the implementations of wide scale constant business rules like temporary store-wide discounts, and minimal deposit fees would/should be placed.

Max Alexander
  • 5,471
  • 6
  • 38
  • 52

1 Answers1

1

In my view, any business rule which deals with allowed states of the data should be enforced in the database. That includes valid individual values as well as valid relationships among values. When you get to process validation, it should be moved to a layer which deals with process. For example, whether a particular state is allowed to transition to another particular state is something which probably doesn't belong in the database, but likely belongs at the next layer up from it.

The various constraints available in SQL, as well as database triggers are good for enforcing rules about allowed state. If a validation involves multiple rows or tables, you may need to worry about transaction isolation level and/or explicit locking to get it right, and those are database features.

kgrittn
  • 18,113
  • 3
  • 39
  • 47
  • So what is a good common practice? Another class library that deals with such transactions? Or embed this logic in the service layer? – Max Alexander May 15 '12 at 16:06
  • 1
    "Best practice" is going to depend a whole lot on your development environment. In my experience, it makes sense to have layers which separate GUI and database from application logic, as abstractions, one way or another. Exactly how many layers there are, where the boundaries lie, and how the API works is not nearly so important as having a clear vision for how to do it that is consistently followed. One or two "rogues" on a project, who feel the need to get "creative" can do much more damage than you might expect. – kgrittn Jun 17 '12 at 23:46