…

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.

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.

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.

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.

The main point about Linq is the delayed execution.
Have you seen the screencast of Rob Conery?
He has a nice way to seperate those things and also uses an ecomerce site as example.

I have also tried Rails. A dissapoint was I have to write 3 times more unit test then in C#, because a compiler already checks a lot of stuff.

var orders = from order in db.Orders
where order.Type == 5
select order;

How can it possibly be beneficial to move that into a data access layer?

I probably should have described the scenario a little better. This is an e-commerce site that has dozens of pages, and they all work quite differently. I’ve bought into the whole layered approach, defining a data model, using NHibernate, etc. I live it every day. I get frustrated when a page with 4 drop down lists takes 5-10 hours because I have to do this:
- Create my NHibernate queries in my data access layer
- Write unit tests for those queries
- Call those DAL queries from the UI (with the hundreds of other queries in there)
- Debug it if it doesn’t work

Then, I have to do it all again to save it. There is SO much code I now have to maintain, and I don’t see how it’s worth it.

How can replacing 20 lines of code with 3 lines of LINQ not be beneficial? I can write the 3 lines of code in 30 seconds, and test it in another 30. That gives me time to make my DAL better for the times when I actually need it.

As I mentioned, this probably doesn’t apply to non-trivial examples.

The point is that some people seem to be too stuck in their old ways of thinking. My background is in enterprise applications, but the simplicity of some of the RoR and DJango code made me jealous, and opened my eyes.

When you have a hammer, everything looks like a nail.