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

The perfect world doesn't exist. It's about elegance versus what works better. Executing complex SQL queries inside data access layers is much more performative than making a service to ask data many times and then merging and transforming them. When you make complex queries you are putting business logic in those queries.

Answer 2

It really depends on the requirements. Either way as long as it's NOT "behind the button" as it were. I think stored procedure are better for "classic" client server apps with changing needs. A strict middle "business logic" layer is better for apps that need to be very scalable, run on multiple database platforms, etc.

Answer 3

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.

Answer 4

Yes, business logic should be in the business logic layer. For me this is the biggest drawback of using store procedures for everything and thus moving some of the business rules to the db, I prefer to have that logic in the BLL in have the DLL only do communication with the db

Answer 5

Separation of layers does not automatically mean not using stored procedures for business logic. This separation is equally possible:

Presentation Layer: .Net, PHP, whatever

Business Layer: Stored Procedures

Data Layer: Stored Procedures or DML

This works very well with Oracle, for example, where the business layer may be implemented in packages in a different schema from the data layer (to enforce proper separation of concerns).

What matters is the separation of concerns, not the language/technology used at each level.

(I expect to get roundly flamed for this heresy!)

Answer 6

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.