LINQ to SQL Stored Procedures w/ Visual Studio 2008
It's actually very easy to use LINQ. And let me dispell a myth here. There is a lot of talk about the advantages and disadvantages of LINQ. Well, I'm here to straighten this out from an Enterprise perspective.
#1 - Is LINQ even for me? Stop BS-ing me
If you have ever worked in an Enterprise environment you know that you never work with something as simple and chumpy (new word, I like it!) as a Northwinds database. But that's all the examples you see.
I, Fabian Agudelo (see my resume), have consulted with many companies. Even the smallest company databases I have worked with had between 50-500+ tables along with numerous associative entities (cross-reference tables) and the most convoluted business logic you could never imagine.
ORE Mappers - For kids only
I have worked with Object Relational Entity Mappers before, but I don't want to name any names because they are brilliant pieces of work. But, if you're even quarter-brilliant you can build a solution more appropriate for your project.
The problem with LINQ at the Enterprise Level
Language Integrated Query offers a very easy OR mapper designer for you. The problem is now you start blending the different layers of a proper n-tier architecture. Most companies have 2+ developers. Maintenance can become a nightmare if database architecture changes. It kind of defeats the purpose of having a seperate DBA if you can do things with a database that a database administrator never intended. Go ahead, do that complex query that your DBA never approved and locked up the database -- see if he doesn't come hunting you down to kill you.
I have many more arguments on this, but I'll squash this soap-box for now.
Lesson learned: Stick with stored procedures.
#2 - LINQ-to-Stored Procs? Sounds like a pain
You would think it's a pain. It's actually as simple as drag-and-drop. You can customize all kinds of things with the IDE. The main disadvantage that I will note is that you can only make changes one-way. So, if there's something unique and cool you want to do with the classes the IDE generated (ie, I often like to override the ToString() function for making my debugging easier and quicker), then those changes will probably not change to the IDE and so going back and forth you could break something.
But, here's a great article:
http://codebetter.com/blogs/david.hayden/archive/2008/02/19/
linq-to-sql-and-stored-procedures-visual-studio-2008-and-repository-factory.aspx
#3 - LINQ is SO SLOW compared to ADO and DAAB - WRONG!!
I too found the article on the internet about performance testing LINQ versus custom ADO.NET, and DAAB (Enterprise Library's Data Access Application Block) and I can tell you LINQ is in fact slower. But, they were testing 10,000 synchronous calls which resulted in many seconds difference. How often is that going to happen? C'mon. If you're doing that, you seriously need to re-think your model for network traffic. Now, on a single call we're only talking as little as 15 milliseconds.
Regardless, consider asynchronous threading models. Definitely look at AJAX if you're in the web world.
Bottom line - Is LINQ for me
I like LINQ. But, going back to section #1 here, yep, that's my biggest reason to stay away from it at the Enterprise level. To me, maintenance and standardization are my primary concerns as an architect. There are too many developers that like to run off and create their own messy code. In today's job world, we can't afford to redo everything because something is too hard to understand or poorly done when requirements change.
Question is, is LINQ for you?
5/20/2008 4:03:48 PM