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 are also technical reasons/limitations to be considered when planning where to author the business rules.

In most LOB applications centralization and performance pushes developers to use the database it self as the primary Business Layer, so in a sense, DAL and BL is mixed or unified.

A typical example would be the field that calculates the current location of a rental item, a piece of information that should be available for one or for many listed items, making an SQL view with a User Defined Function the most powerful candidate to hold the rule.

The above example is valid of course if a specific database design and processes implementation is preferred, but I just want to point out that in real world, we choose based on technical limitations and other principles, more often than we do for organizing our code.