BT

Do You Need a Data Layer?

| by Jonathan Allen Follow 576 Followers on Aug 20, 2007. Estimated reading time: 2 minutes |

With LINQ nearing release, the need for a separate data access layer needs to be reevaluated. Is it still an essential part of an application's design? Or has it become an appendix of the past?

The essential problem is that LINQ blurs the lines between the data access layer and the business layer. Kris Vandermotten discusses this when he explores LINQ-based data access layers in his 2-post series, Creating a Data Access Layer with LINQ to SQL.

In his first experiment, Kris creates and returns a query from the data access layer. Kris discusses some problems involved with this, which can be summarized as:

  1. Unlike a traditional data layer, in this design the query is actually executed in the business layer.
  2. The business layer has the ability to redefine the query.
  3. It is unclear where exactly the boundary between the layers are, forcing developers to make choices like where to put order by clauses.

I hate it when developers have to make choices like that during routine development. Choosing takes time, and that’s not likely to improve productivity. But much worse is the fact that different developers will make different choices. Even a single developer may make different choices from one day to the next. That leads to inconsistencies in the code. Developers will spend more time trying to understand the code they’re reading, because it doesn’t always follow the same pattern. That’s bad for productivity. In the worst case scenario, developers start rewriting each other’s code, just so it matches their choice of the day. That kills productivity. (Wasn’t Linq all about improving productivity?)

Kris comes to the conclusion,

I’m inclined to say that the only way to make a clear and simple choice once and for all, it to go with the minimalist approach. And indeed, that means we don’t need/write/use an Entity Access Layer. The business logic directly accesses the one assembly generated by SQLMetal.

Adam Herscher looked at LINQ as well, but came to an entirely different conclusion.

So, to wrap this post up… after roughly a day of investigation, it’s safe to say that we’ve come to the conclusion that while LINQ is a promising technology, and could potentially replace much of the overhead in designing, implementing, and maintaining a data access layer in the future, it’s no silver bullet today. We’ll likely incorporate it into our system in some capacity (i.e. as syntactic sugar for querying SQL), but it will likely remain abstracted by a set of data access mechanisms that will still be required for any data that is likely to be cached, partitioned, or accessed by multiple components/tiers now or in the future.

While it is certain that LINQ will change the way .NET applications are written, it may be quite some time before the community comes to a consensus on design patterns.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Sounds dangerous... by Jason Carreira

I'm no .NET developer, but I think I'd be wary of getting too entangled with one of their new APIs. Microsoft has a history of pulling the rug out from under their developer base, leaving them scrambling to port old code to the new hot (and incompatible) API.

It may not be a sexy new thing, but layered architectures are there for a reason, and you dismiss them at your own peril. I think the second quote has it about right... keep it behind a well defined internal API and cordon it off from the rest of your code. Don't let it seep into your business logic or you'll feel the pain later.

Re: Sounds dangerous... by Stefan Wenig

I wonder where you got that impression. I think MS is often more obsessed with supporting stuff from the past than they should. I'd sometimes rather live with a few breaking changes.

Re: Sounds dangerous... not really by Saad Khawaja

Once you start using an orm solution that uses reflection/proxies, It is very unlikely that you can go back to a simple ADO based data access layer. The orm framework will do some many things behind the scenes that you will be practically locked-in to the solution. That being the case data access layer loses some of its value. Mainly providing a pluggable layer for different data access mechanisms. So we can get rid of the data access layer and merge it with the service layer and most of the business logic will move to the domain layer.

I have to agree with Stefan Wenig by Maximilian Schulz

I think you are absolutely right. Microsoft is so concerned with backwards compatibility, that their libraries get overcrowded and strangely structured. You get used to it when working fpr years, but for newcomers, it is really hard to handle all the stuff. Moreover, conventions change and break with old styles, still these "no longer valid" ones remain in the system... Ok, i am getting excursive… but I think one should break with old habits from time to time!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT