Comments on: Do you really need a data access layer with LINQ?

By: Alwin Goh

Alwin Goh — Sat, 12 Feb 2011 01:58:48 +0000

Hi, though its been a while since you first posted this, I’d like to say that I have the same conclusion as you. While I deem that both the UI and Biz layers are still there, the dataaccess layer is now different, though not redundant. What used to be lots of SQL statements in the DAL is now superceded by the LINQ (to whatever) commands which pool and generate to underlying native commands. The level of reusability afforded by LINQ is not something easily achievable by a traditional DAL (why not try combining different DAL methods to achieve 1 unified operation, it will be something short of perfect…), unless you had the skill to achieve the same kind of command reuse possible with LINQ, which is beyond the time (maybe not brains) of most people. With LINQ, I think the data access layer now consists of 1) the provider, 2）the context/entities, 3) And maybe any extra data definitions (physical, logical), mappings… plus a global connection string setting somewhere.
DALs are not gone, just changed, and LINQ just looks like SQL, it is not SQL – it is a general purpose query language for getting things, it is a very important improvement. Hence, LINQ can be used in UI or Biz layers, depending on how you use it.

By: Abubakar

Abubakar — Fri, 09 Jul 2010 05:44:40 +0000

this is good technique About the Linq Which use in asp.net3.5 That is good visual Studion Becasue
this is user friendly

By: Carlos ABS

Carlos ABS — Fri, 14 Aug 2009 14:15:14 +0000

Hi!

I’m developing a brand nem e-commerce website and had the same insight.

I was developing in the “old way”:

U.I. -> B.O.L. -> D.A.L -> Stored procedures

Then i was introduced to LINQ and the more i used it, the more i realized that my DAL, BOL and stored procedures, IN THIS CASE, are useless.

I’m not 100% sure about this, but i’m planning to remove all those “useless” and work just with LINQ by now.

I used a third part objects/procedures generator but LINQ to SQL is doing the “dirt work” for me now.

By: Karl Kemerait

Karl Kemerait — Wed, 14 Jan 2009 13:43:56 +0000

Nice thought process, in general I agree with you, I would even sugest that we could go further. I tend to think the most of the “best practices” that follow today are designed to be “best proactices” for applications that are much larger than the one we typically work on. I think it’s time to look at a second set of “best practices” that more closely matches our daily tasks and priorities.

http://designlunacy.blogspot.com

for my latest rant on “involving users in design”

By: Dew Drop - May 8, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - May 8, 2008 | Alvin Ashcraft's Morning Dew — Thu, 08 May 2008 13:16:48 +0000

[...] Do You Really Need a Data Access Layer with LINQ? (Jason Young) [...]

By: teedyay

teedyay — Thu, 08 May 2008 09:49:08 +0000

Mmm, thanks for the popcorn, Will!

There’s some quite strong opinions on this page, but I can see where you’re coming from: LINQ makes it so damn easy to write queries in the code behind your page, but something makes me feel a little uncomfortable doing that.

Just lately I’ve been trying to put most (all?) of the DB-accessing LINQ queries into the non-generated half of my DataContext class, just so it’s all together in one place, giving me my data access layer.

This is fine for encapsulation, but feels a bit like over-engineering when it’s a simple query I only use on one page.

LINQ’s DataContext has been quite a paradigm shift for me in terms of how I use ORM. For me at least, the jury’s still out on issues like this.

By: superjason

superjason — Thu, 08 May 2008 01:35:36 +0000

“Eventually you’ll come to the realization that common linq queries belong in a common class accessed by all pages” – I agree, but what I’ve seen, at least on the last site, common queries are more rare than I would like. Each page usually has different requirements. When I’m writing code, I’m very conscious of rewriting the same functionality. When that happens, of course I’m going to try to re-use my code.

Chad, I agree. I think I’ve unsuccessfully conveyed the situation that I’ve run into. I’ve tried to apply my background in large application development, to individual pages with their own unique functionality. I don’t regret insulting people, since I was including myself in that group. I’m simply suggesting that a hard and fast rule of trying desperately to separate out DAL logic might not reap the benefits we would expect.

In the site I just created, I had all the layers, and they were completely separated. I was able to test any layer regardless of the other layers. The site is reliable thanks to 700 unit tests, but at the expense of having 10x as much code to maintain. Am I really better off? I’m not so sure!

Honestly, I would have rather saved all of that time, and spent it on the critical pages. For example, I would have liked to had a full MVC unit testable checkout process.

By: Chad Myers

Chad Myers — Wed, 07 May 2008 23:57:00 +0000

@superjason: Stop insulting people (re: hammer/nail) and try to consider why the ‘db.Orders’ might be a problem if you ever wanted to use that code against something other than a database (i.e. test data). If you’re happy with tightly binding all your code to your database and sure that you’ll never re-use that code for anything else, then why do any layers and just have one solid layer and put everything in the code behind or directly in the view?

By: logicalmind

logicalmind — Wed, 07 May 2008 22:17:30 +0000

It all depends on project size. If you are a single developer writing all the code and all the pages then of course it’s going to be easiest for you to write the least amount of code. Once you introduce more developers to the project that starts to fall apart.

Are you suggesting that whoever is writing a page determine what linq queries they use and just write those in their page? Eventually you’ll come to the realization that common linq queries belong in a common class accessed by all pages. Separate people can write these separate layers as would be the case in projects with more than one developer. Once you do this you’re back to where you started except you’ve replaced nhibernate data access layer with linq for sql data access layer.

By: superjason

superjason — Wed, 07 May 2008 21:47:23 +0000

Our business objects match our database. It was written from the ground up that way. We use OR-mappers exclusively.

Code changes will trigger compile errors (when using Linq), and we’ll know where to make the changes.

I’ll check out the Linq screencast you mentioned. I would like to see a good ecommerce example.