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

If you are building a layered architecture, and the architecture contains a dedicated business layer, then of course you should put business logic there. However, you can ask any five designers/architects/developers what 'business logic' actually is, and get six different answers. (Hey, I'm an architect myself, so I know all about 'on the one hand, but on the other'!). Is navigating an object graph part of the data layer or business layer? Depends on which EAA patterns you are using, and on exactly how complicated/clever your domain objects are. Or is it perhaps even part of your presentation?

But in more concrete terms: database development tools tend to lag behind Eclipse/Visual Studio/Netbeans/; and stored procedures have never been extremely comfortable for large-scale development. Yes, of course you can code everything in TSQL, PL/SQL &c, but there's a price to pay. What's more, the price of having several languages and platforms involved in one solution increases maintenance costs and delays. On the other hand, moving data access out of reach of DBA's can cause other headaches, especially with shared infrastructure environments with any kind of availability requirements. But overall, yes, modern tools and languages are currently moving logic from the data(base) layer into the application layer. We'll have to see how well it works out and scales.