LINQed IN

Blog by Troy Magennis on Software Architecture, Development and Management

About the author

Troy Magennis is a software developer living in Seattle, WA. Troy is a Microsoft MVP, the author of many articles, and the founder of HookedOnLINQ.com, a LINQ specific wiki reference site.
E-mail me Send mail

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008

Will LINQ eliminate stored procedures? or just a more intelligent way to access data?

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.


Posted by t_magennis on Thursday, September 27, 2007 5:20 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Visual Studio Code-Comment Hyperlinking Add-In

I follow Brad Abrams blog and saw that he posted on a very nicely implemented Visual Studio add-in component that allows hyperlinking within code-comments.

Vance Morrison (the author of the tool) talks about making code more approachable and how he feels this type of add-in supports getting new developers understanding code faster.

Download it from CodePlex here: HyperAddIn

The main features of the HyperAddin are  

  • Anchors and Hyerlinks in your code comments.   Quickly navigate to related parts of your code by simply clicking on a hyperlink in your comments.
  • 'GoOut' Navigation.   Quickly find the method, class, and top of the file of the method you are currently in.  These places are where you should be put  interesting comments about the 'big picture' comments about the design of the code. 
  • Word wrapping in comments.  Form nicely justified paragraphs in your comments with one click of the mouse. 
  • Supports both C#, C++, JScript and VB style comments. 

Vance also asks -

If you like the capabilities of HyperAddin and wish that Visual Studio had this feature, you can vote on this here.  To vote, click on the 'Sign in to Rate' (and register if necessary), and then click on the number of stars in the rating box that corresponds to the value of this feature.   The more people who vote, the more likely this feature is to get into Visual Studio.

I'm in favor of any feature that makes code I have to maintain easier to work with. He has my vote.

Troy.


Tags:
Categories: Resources
Posted by t_magennis on Wednesday, September 26, 2007 5:18 AM
Permalink | Comments (0) | Post RSSRSS comment feed