Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Do You Need a Data Layer?

Do You Need a Data Layer?

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