Do you really need a data access layer with LINQ?

home
linq
view story

14 Kicks

Do you really need a data access layer with LINQ?(ytechie.com)

submitted by SuperJason(2740) 4 years ago

Some thoughts on skipping the creation of a data access layer in a web application that uses LINQ for all of its database access.

4 comments |category: Linq |Views: 85
Tweet

tags: Bullshit LINQ another

Everyones tags:

Your Tags:

Please login or signup.

Add a live kick counter to your blog >> liveImage

You can even customize the image by choosing your own colors, and then clicking the button below to update the preview and the html code:

"Kick It" text
"Kick It" background
kick count text
kick count background
border

Simply copy and paste this HTML into your blog post.

Users who kicked this story:

adron(835) -

khushal999p(275) -

nsoonhui(1810) -

Jemm(9604)

More who kicked this story...

Comments:

posted by ussherm(5285) 4 years ago 0

Calling your queries (even if querying via EF) directly from the UI layer is... EPIC FAIL!!!

Is there any way I can negative-kick this article?

posted by offwhite(975) 4 years ago 0

I think different kinds of applications have different priorities. Assuming every application has to be a multiple tier architecture is a failed assumption. But generally any widely used application that will be updated and released many times for more than the most brief period should be at least be modular enough to be flexible. A LINQ layer, perhaps a DataContext in a class library that features supporting classes to query the LINQ DataContext may be a sufficient data access layer. But I agree that calling into the DataContext directly from the UI layer is nearly always bad form.

When I throw together QA pages to simply display data in the staging and production environments I do directly bind them to tables in the database to completely bypass any business logic or complications in the data access layer in order to hopefully reveal the root cause of a bug. Still, I do like to lock down the database to only have EXEC rights on stored procedures and not even allow read access on the tables. Lately the projects I am on do not allow for that level of control in the data access layer. In the last project I actually used SubSonic. At least it provides a good level of compile-time protection because I always made use of the constants for the tables and column names in the queries.

posted by dengar007(3084) 4 years ago 0

No offense but I'm not a big fan of this idea either. Maintaining an application would be a nightmare.

posted by JudahGabriel(814) 4 years ago 0

Tagged appropriately -- too many folks throw business logic, data access, etc. into their views. This encourages what is generally an all-too-common bad idea.

Most Active Users

What's this?