Should the data access layer contain business logic?

Question

I\'ve seen a trend to move business logic out of the data access layer (stored procedures, LINQ, etc.) and into a business logic component layer (like C# objects).

Answer 1

There will likely always be some level of business logic in the data layer. The data itself is a representation of some of that logic. For instance, primary keys are often created based on business logic rules.

For example, if your system won't allow an order to have more than one customer is part of the business logic, but it's also present (or should be) in the Data layer.

Further, some kinds of business rules are best done on the database itself for efficiency reasons. These are usually stored procedures, and thus exist in the data layer. An example might be a trigger that goes off if a customer has spent more than $X in a year, or if a ship-to is different from a bill-to.

Many of these rules might be handled in the business layer as well, but they also need a data layer component. It depends on where your error handling is.