CSLA .NET

    I have been learning and playing with LINQ for a while and really like it.  I have found a few quirks with it and am wondering what the general consus among developers is out there.  I am in the process of re-architecting a SQL Server 2005/MS Access application that uses ODBC and am trying to figure out which way to go.  The application has over 300 tables and supports about 20 users for a medium sized oil company.  And no, we are not rolling in $ like Exxon.  We are actually getting hammered.  But anyway, has there been anyone who has developed a large scale application utilizing LINQ that has also developed a large scale application utilizing ADO.NET utilizing SQL stored procedures.  I have developed a number of large applications utilizing ADO and SQL stored procedures but am curious about someone with LINQ experience also.

    Anyway, any info would be helpfull.

Keith

It's not necessarily an "either or" situation.  I haven't used LINQ in a production application yet, but mostly because my former DBA forbade it based on info from the beta days.  I spent a fair amount of time researching it to solve some fears about it.

* in the LINQ designer you can drop sprocs just like tables.  They show up in the side bar as methods, but you can use them in your queries more or less the same way.

* You can also instruct the tables to use specified stored procedures for insert/update/retrieve operations.

This solved the "we must use stored procedures" mandate for me.  Using these two methods you can use LINQ to SQL to easily populate business objects while funneling all of the SQL through stored procedures.  In other words, your DBA will never know.

If you don't go the sproc route, I would recommend using the built in logger to evaluate the queries being generated during development.  Usually they're pretty good, but every once in a while it does something wonky.

Justin

First off, LINQ has nothing to do with working with databases. I'll assume you are refering to LINQ to SQL or Entities.

With LINQ to SQL, as long as your objects closely match up with the table structures you are using, and you are primarily using simple CRUD operations, you should be fine using it. Stored procs are more useful in cases where you need more complex logic or complex joins, or in cases where thousands of people are hitting tables with millions of rows. With only 30 people hitting your applciation, I assume the processors on your SQL Server are sitting idle most of the time, so performance shouldn't be that much of a concern.

If there is a mismatch between your tables and objects which require complex joins, I would recommend using LINQ to SQL against stored procs or possibly the entity framework.

Jim Wooley
www.LinqInAction.net
www.ThinqLinq.com