Head First | The Coffeehouse

SaraJoRedux
GirlDeveloper.com

So, I was origionally going to use stored procedures and active record sets in this project, but the more I read about MVC and LINQ the more I realize iot will make my life SO much easier.

So I'm going through Scott Gu's tutorial now getting up to speed, I think this time investment will prove worthwhile.

Has anyone implemented them in a project?

How does it affect performance? Faster? Slower? Same?

jh71283
Throw new System.Beverage. OutOfCoffeeException()

quick word about Scotts tutorial: there was a breaking change after that tutorial was written, so instead of .Add(Object) it is now .InsertOnSubmit(Object)

SaraJoRedux
GirlDeveloper.com

In reply to jh71283

#Jul 10th, 2008 @ 12:05 PM

Thanks.

I'm hearing rumors about LINQ not being scalable for larger apps and it cutting down on performance speed.

Any validity to this?

HumanCompiler
Compiling humans...and code

In reply to SaraJoRedux

#Jul 10th, 2008 @ 12:10 PM

Depends on what you're doing. Only thing I've seen is doing lots of updates can be slow, but that's because LINQ does pessimistic concurrency. This is easily avoided by writing your own Add, Edit and Remove stored procedures to use instead. No performance problems with Selects that I've found yet. It's quite good at coming up with the most optimized statement possible.

EDIT: Or is it optimistic concurrency? I always get those two mixed up.

vesuvius
Das Glasperlenspiel

The principal problem with Linq is that there is no change tracking. It's sweet for small apps, but I would steer well clear of it in larger applications. Sprocs are cumbersome to begin with, but pay you back later. Linq pays you back straight away, but is beyond cumbersome later.

With Linq it is possible to make something or anything work, but if you want to adhere to patterns and practices, or just simple 'best practices', it is somewhat lacking in maturity. The ADO.NET entity framework is gathering pace, but this is Version 1.0 as far as Visual Studio is concerned and Microsoft will have cut corners. Pragmatism would dictate you wait a while longer.

You may as well leverage your existing skills, because by the time you've fully learnt this new ADO.NET layer, the project will be in the red!

SaraJoRedux
GirlDeveloper.com

In reply to vesuvius

#Jul 10th, 2008 @ 12:27 PM

Thakns guys, I think I'm going to stick with tradtional stored procs and then go with the MVC.

figuerres
???

In reply to HumanCompiler

#Jul 10th, 2008 @ 12:24 PM

Also what linq does when you are inserting and updating is it sets up a transaction.

this is generally a good thing but it may not know that some tables need to be part of the transaction and others do not.

but the fact that it will be a trasaction and if it fails it all rollsback is usefull ....

when I started to use linq I went looking for a .BeginTransaction() and did not find one... then learned it was automatic.

I have one web service that is using linq to insert orders into a database, so far all the inserts are for sure less than 1 second.
how much less I have not yet checked.... but this is a very busy database and has piles of inserts going into it from an older webservice that users sprocs and C# / no linq.

so far it seems like the two services play well with each other.... both of them hiting the same tables and doing the same job.