I get LINQ, but what does this mean for stored proc's?

OK I get LINQ! Coding to a database is a pain in the neck at the moment and LINQ and its variants are aiming to make that easier.

My concerns are really very simple ones and I do accept that I may’ve missed the point. Anyway here goes …

Is this the write place to put database query code? I like everything to be in nice little easy to find and all in nice little boxes, so I like layers and abstraction. I mish-mash is not good in my book. So can I change a LINQ query after I’ve compiled my .Net executable?

I’m still a firm believer in stored procedures, are they old tech now?

If so, are these newer technologies going to compete in terms of performance? What are the limitations of stored proc’s, what have I missed? Couldn’t we solve our issues by just making it easier to connect to stored procs?

From my point of view,  this is like CLR integration into SQL 2005.  In some situations it is right, in others it is wrong

I think LINQ is another great tool in a developers toolbox.  I still feel SPOs are the way to go for most things, but there will be some times when LINQ is better.

LINQ == Replacement for 20 page spo

SPO == Quick join on three tables



Might be wrong tho - this is just how I see it.

LINQ is completely in the client, so you don't get the fun of precompiled SPs.

A very interesting topic.

IMO Sprocs are not a great strategy for an application that needs to be able to work againtst multiple RDbMS'. In fact, I think that LINQ is trying to answer what I have seen in several products - a RDbMS-independent layer above the database.

I too am uncertain as to the architectural wisdom of locking database logic into code, but I think that most product vendors would already be forced into something like this by the demands of using only SQL-92 compliant statements, and making certain RDBMS tweks at runtime.

Besides, prepared statements/meta-data can give you a lot of the non-compiled support you would get out of sprocs.

my two cents.

I think this is where the Entity layer from the missing ADO.Net video could come in handy. You could define entities in terms of their physical table layout or sprocks and database views, and then use LINQ to create strongly typed queries based on entities.

So its compiled LINQ expression -> DLINQ provider -> (eSQL) -> Ado.Net Entity Mapper -> (Sprock Call) -> Database

Database -> (Result Set) -> Entity Mapper -> (Entity Record) -> DLINQ -> Strongly typed object.

Its really wierd, all the white papers have now been pulled as well.

littleguru wrote:

LINQ is just delegates that loop over collections and return you the matches. You may apply sorts etc. This all happens in the client and has nothing to do with databases.

littleguru wrote:

LINQ is just delegates that loop over collections and return you the matches. You may apply sorts etc. This all happens in the client and has nothing to do with databases.

Yeah, they're not meant to replace stored procedures. Could you imagine getting rid of srored procs? Every query change, you would have to recompile dll's and toss them back onto the servers, thus killing any active sessions. Not a good solutions for an e-store, for example. =)

The May LINQ CTP has all new/updated documents, and the stored-proc interface is covered nicely.

DLINQ documents provide some examples of using ExecuteCommand() to execute StoredProcs as part of a DLINQ function.