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

It is ALWAYS a good idea to separate your layers. I can't tell you the number of times I've seen stored procedures that are VERY gnarly from lots of business logic written into the sproc. Also if you modify your complex stored procedure for whatever reason, you have the potential to break EVERYTHING that uses it.

Us devs at my company are moving to LINQ w/ the EF and dismissing the stored procedure unless we absolutely need it. LINQ and the EF make separating our layers a lot easier...when the EF is not being difficult. But that's another rant. :)