I got this email today posted from the HookedOnLINQ Wiki I host:
Troy --
I am a new developer to the LINQ framework and had a few questions that I hope you can field.
Looking at a broad overview of LINQ, I see it as a way to simplify development, but it also raises a few other questions. As most devs, I've been using the N-Tier architecture for having my applications access the data stores, requesting stored procs to do the processing, and returning the information that I'm interested in.
Is LINQ providing a way to eliminate the uses of stored procs, or is it just providing a more intelligent way to access the data?
For instance, in the past the way I have handled data access would be to have a separate class that shadows my stored procedures in my database. When ever I would make a stored procedure, I would then have to go into my database interface class and create a subroutine with matching signatures to the stored procedure. It would provide error checking, execute the data access object, then return a dataset for further processing. From there it would loop through the dataset and display information as required.
When I think LINQ, the first thing that pops into my head is, will this eliminate that second layer? Does LINQ provide a way to directly access the database without having to go through the process of constantly of creating a procedure, changing my code, and redeploying.
I've also had it hammered into me in the past that Inline SQL from within my code is a bad idea due to maintenance concerns.
As you can see, I am a bit confused. I went over the 5 minute prep on your website, and understand manipulating objects with LINQ, but I'm not sure I get the whole picture.
Appreciate it,
G...
All very good questions. I tried to answer some of them, but I must confess - I'm really interested to see what LINQ's impact is over the next few years.
Hi G...,
I think the full LINQ story and what code it will replace is unfolding. Although I'll take a shot at answering some of your excellent questions:
1. LINQ to SQL can be used in a way that eliminates the need (in the vast majority of cases) for writing and maintaining Stored Procedures. You can write LINQ queries, update the returned object structure and apply changes back to the database without stored procs.
2. For LINQ to SQL to operate it needs to map its data entity classes to your database. You essentially have Three options,
a) markup your own classes using LINQ .NET attributes ie. [DataColumn]
b) use the DBML designer and drag tables from the Server Explorer in Visual Studio
c) use an XML mapping file to link database objects to classes
You do need to keep these in synch when you database structure changes. This will be interesting to see how teams solve this problem.
3. Inline SQL is bad from a "SQL injection" perspective (where malformed input into a text box could cause SQL you didn't really plan for being executed on your server). The mitigation for this is to pass data to the database via SQL parameters. LINQ does this (as do stored procedures, which is why they were the traditional workaround"
4. I think with LINQ, you are maintaining C# code which is type safe and checked during compilation. Inline SQL is just a string and you will only see it fail when it is executed (hopefully on a test box before it reaches production!). The jury is still out as to what maintaining over time a large amount of C# LINQ to SQL queries will be like - But until then, enjoy the intellisense, type checking and working in one coding language instead of two!
Hope this helps a little. Feel free to ask for clarifications,
Troy Magennis
Did I answer G....'s questions?
Troy.