April 23, 2008 at 10:02 am
A close friend of mine was at a conference in Vegas recently, and described a demonstration put on by Microsoft that proved LINQ coding performed faster than stored procedure access... SO WHAT!!!
Well the point of that session, was that ALL developers should be moving to LINQ. I really have a hard time whenever I hear that from Microsoft, because... what if they really mean it?
I haven't done any coding using LINQ. I've read through sample code and it looks easy enough, but what about maintainability?
MAINTAINABILITY! MAINTAINABILITY! MAINTAINABILITY!
I never hear that argument made when discussing the pros and cons of this new tool. After reluctantly learning, then embracing T-SQL years ago, I find my "programming" time equally divided between the client interface and the stored procedures that support it. Moving the server code into the client application (even ASP) just doesn't feel right yet. It's sort of like making a u-turn.
All that I can do is to keep reading and watching. Maybe I'm wrong, and when I believe that, I'll reluctantly learn and embrace LINQ. Until then I might try it on some other data sources than SQL Server.
Thanks for another stimulating topic Steve. Keep them coming!
April 23, 2008 at 11:59 am
Tom Garth (4/23/2008)I haven't done any coding using LINQ. I've read through sample code and it looks easy enough, but what about maintainability?
Like I said before in my earlier comment, LINQ is way more than just a way to get data out of your database. LINQ to SQL is what that functionality is named and it's just a part of a much larger LINQ universe, if you will. I guess this being a DBA oriented place this part of LINQ is being emphasized more though.
LINQ is a tool that you can use in whatever way you want. If you want to have it create the underlying queries needed to get data out of your database, by all means have at it. If you still want to get data out the way you're doing now, presumably by using stored procedures, you can do that to. Either way once you get your data from the database, in whatever manner you want, LINQ still has a role to play. The keywords it introduces, such as from, where, select, orderby, group, and join may look like SQL but they're not! Those keywords use lambda expressions, extension methods, and anonymous types to enable SQL-like syntax for manipulating your data on the client side. You can use LINQ for manipulating an array, for instance, that had nothing whatsoever to do with a database.
LINQ can be no more or less maintainable than your existing C#, VB, etc code.
April 23, 2008 at 12:25 pm
Timothy (4/23/2008)
Tom Garth (4/23/2008)I haven't done any coding using LINQ. I've read through sample code and it looks easy enough, but what about maintainability?
LINQ can be no more or less maintainable than your existing C#, VB, etc code.
Timothy,
I was referring to maintaining the code in a SS stored procedure v. maintaining external code that manipulates the data.
Your comment is well said, and goes beyond the general discussion in an enlightening way.
Thanks,
April 23, 2008 at 9:06 pm
I think LINQ -> SQL gets more play overall. At some of the developer presentations I've seen, it's always the highlight and gets most of the time. The people up in Redmond seem to see it as the part of LINQ used most often.
I'd like to see some people use LINQ and report back how it goes. LINQ is a 1.0 tool and it's an idea Microsoft is presenting, but I'm not sure it's the best way to build things. Time will well. Just like agile has evolved in a few ways (and it's not for everyone), I'm sure LINQ will evolve as well.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
April 24, 2008 at 6:42 am
Everything we do is through stored procedures and this will not change. I have several problems with LINQ not the least of which is trying to use it in Silverlight 2.0. While I find Silveright to be a great improvement for UI development, it is all but completely lacking in data handling. We would love to be able to leverage a lot of our existing .NET code but can not because there is no support for ADO Datasets (disconnected of course) which we use extensively as faux business objects. It seems that we are going to have to create our own implementation of an ADO dataset in Silverlight. While I can appreciate new things like LINQ, I feel that support for the millions of lines of code already written should be considered a basic requirement. I realize that Silverlight can not have connected ADO datasets, but the ability to rehydrate a disconnected dataset and manipulate it in Silverlight would be a huge advantage.
[font="Verdana"]Samjazz[/font]
April 24, 2008 at 6:52 am
The claim that LINQ saves 1/3 of the development time is inaccurate, since writing CRUD stored procedures is a no-brainer that takes very little time and can be automated with tools such as erwin. For my team LINQ is a huge step backward in time. I had in-line SQL capability in the 90's with Powerbuilder and we rejected that in favor of Stored Procedures even then. For developing new UIs for existing databases, where the SPs for CRUD are already developed saves NO time.
[font="Verdana"]Samjazz[/font]
April 24, 2008 at 7:02 am
Steve Jones - Editor (4/23/2008)
I think LINQ -> SQL gets more play overall. At some of the developer presentations I've seen, it's always the highlight and gets most of the time. The people up in Redmond seem to see it as the part of LINQ used most often.I'd like to see some people use LINQ and report back how it goes. LINQ is a 1.0 tool and it's an idea Microsoft is presenting, but I'm not sure it's the best way to build things. Time will well. Just like agile has evolved in a few ways (and it's not for everyone), I'm sure LINQ will evolve as well.
Here's a bit of C# code I used to join an in-memory data collection to populate a Repeater ASP.NET control.
this.repeaterDuplicates.DataSource =
from d in dups
group d by d.LocationID into g
join l in Global.Locations.AsEnumerable() on g.Key equals l["LocationID"]
select new { ID = l["LocationID"], Name = l["Description"] };
The dups variable in that code is an array of DuplicateTimesheetHours objects which was populated by a call to the database a few lines above this one. Global.Locations in that code is a cache of a typed dataset that I retrieve from the database when the application first starts. It's a lookup table that hardly ever changes so instead of requesting that data every time I need it I just cache it.
Thanks to the join capability of LINQ when I get my duplicate timesheets from the database I don't also have to send over the description of the location the timesheet belongs to, since I already have that via Global.Locations. Prior to LINQ I found it to be more convenient to do the join with my lookup table on the SQL Server side and send over the description in my result set, even though I would already have that lookup table on the client side.
April 24, 2008 at 7:15 am
sfrabotta (4/24/2008)
The claim that LINQ saves 1/3 of the development time is inaccurate, since writing CRUD stored procedures is a no-brainer that takes very little time and can be automated with tools such as erwin. For my team LINQ is a huge step backward in time. I had in-line SQL capability in the 90's with Powerbuilder and we rejected that in favor of Stored Procedures even then. For developing new UIs for existing databases, where the SPs for CRUD are already developed saves NO time.
You have to remember that .NET is typically marketed foremost a RAD tool. As such, I can see how linq is pitched as a timesaver to developers doing quick corporate type, small scale projects. In my experience, 90% of .NET websites are this way. This is why it can be very difficult to get a good .NET contracter. It takes at least 20 or more interviews to find the good ones.
Once you start developing in a more disciplined way and use .NET to produce higher quality code, then you typically adopt patterns, practices, and a basic technology toolset. Once you are doing development this way, then yes things like linq are not really the huge timesavers they are to the guy just trying to do something quick and dirty (which, unfortunately, or more often than not the kind of app that gets developed)
April 24, 2008 at 7:18 am
Timothy,
Your example is a good use of Linq, yet does not use Linq To SQL which is the Linq implementation most folks on this thread take issue. I think your example is how MS is thinking Linq will be used. We need to remember that Linq stands for Lanquage Integrated Query and is really designed to give developers a single way to query anything and that Linq to SQL is just one of many ways to use Linq.
I think Linq is a step forward, but that the Linq to SQL implementation could be better.
Mike Taulty has a "rant" on his blog about the way the term Linq is being misused which everyone should read.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
April 24, 2008 at 7:25 am
Samuel Clough (4/24/2008)
sfrabotta (4/24/2008)
The claim that LINQ saves 1/3 of the development time is inaccurate, since writing CRUD stored procedures is a no-brainer that takes very little time and can be automated with tools such as erwin. For my team LINQ is a huge step backward in time. I had in-line SQL capability in the 90's with Powerbuilder and we rejected that in favor of Stored Procedures even then. For developing new UIs for existing databases, where the SPs for CRUD are already developed saves NO time.You have to remember that .NET is typically marketed foremost a RAD tool. As such, I can see how linq is pitched as a timesaver to developers doing quick corporate type, small scale projects. In my experience, 90% of .NET websites are this way. This is why it can be very difficult to get a good .NET contracter. It takes at least 20 or more interviews to find the good ones.
Once you start developing in a more disciplined way and use .NET to produce higher quality code, then you typically adopt patterns, practices, and a basic technology toolset. Once you are doing development this way, then yes things like linq are not really the huge timesavers they are to the guy just trying to do something quick and dirty (which, unfortunately, or more often than not the kind of app that gets developed)
Agreed. Most true RAD methodologies define RAD projects to include an already completed database. What I think linq really does is encourage "cowboy" coding.
But, while LINQ doesn't work for my shop, I am not against it if that's what people want to use. My biggest problem at this point is that there is no alternative (traditional ADO.NET dataset support) in Silverlight 2.0. It is frustrating the heck out of our team because we really want to use Silverlight for our new developent.
[font="Verdana"]Samjazz[/font]
April 24, 2008 at 8:02 am
Jack Corbett (4/24/2008)
Timothy,Your example is a good use of Linq, yet does not use Linq To SQL which is the Linq implementation most folks on this thread take issue. I think your example is how MS is thinking Linq will be used. We need to remember that Linq stands for Lanquage Integrated Query and is really designed to give developers a single way to query anything and that Linq to SQL is just one of many ways to use Linq.
I think Linq is a step forward, but that the Linq to SQL implementation could be better.
Mike Taulty has a "rant" on his blog about the way the term Linq is being misused which everyone should read.
Yeah, I realize I'm not using LINQ to SQL to create queries, and honestly I probably never will for the reasons many are objecting to it on this thread. That link you had though is exactly why I wanted to comment on LINQ though: LINQ does not equal LINQ to SQL. I remember when ASP.NET 2.0 came out Microsoft was hawking the new controls, such as the Login suite of controls to make creating login pages easier. I tried them out and almost immediately went back to the way I was doing things; but I still loved most other introductions to ASP.NET 2.0. Some things Microsoft introduces are more for beginning programmers and some things aren't. I think LINQ is a great technology so I hope others don't throw out the baby with the bath water in their rejection of LINQ to SQL.
sfrabotta (4/24/2008)
My biggest problem at this point is that there is no alternative (traditional ADO.NET dataset support) in Silverlight 2.0. It is frustrating the heck out of our team because we really want to use Silverlight for our new developent.
I've looked some at Silverlight 2.0 and I'm seriously thinking about using it in place of ASP.NET when it's out of beta -- I'm so tired of browser incompatibilities, CSS limitations, etc. But I'm kind of surprised to hear there's no dataset support in it. I know with .NET 3.5 DataContexts are the "new" DataSets. Have you looked into using them? Since you ultimately end up programming against IEnumerable derived classes, instead of classes derived from DataSet / DataTable, you could construct objects that had the same properties as your typed datasets so things wouldn't look so different to your existing code. DataTables aren't derived from the IEnumerable interface so they're a bit harder to work with in LINQ, which uses that interface extensively.
April 24, 2008 at 8:25 am
Timothy (4/24/2008)LINQ does not equal LINQ to SQL. ... I think LINQ is a great technology so I hope others don't throw out the baby with the bath water in their rejection of LINQ to SQL.
Timothy,
Same reason I made my comment on your example. I really like the idea behind Linq, especially the ability to "join" objects. The power of Linq is NOT Linq To SQL, but in the common method of "querying" objects and being able to "join" them.
I actually am not against Linq To SQL either, I just wish MS had made it easier to use sp's in Linq and/or did something like iBATIS.NET does (I just learned about this on this thread and it is not an ORM tool like Linq) where you can map your database queries outside the classes created by Linq To SQL.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
April 24, 2008 at 8:39 am
Great information and points, and if anyone wants to write on their LINQ experiences, SQL or not, let me know.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
April 24, 2008 at 9:12 am
Jack Corbett (4/24/2008)
I actually am not against Linq To SQL either, I just wish MS had made it easier to use sp's in Linq and/or did something like iBATIS.NET does (I just learned about this on this thread and it is not an ORM tool like Linq) where you can map your database queries outside the classes created by Linq To SQL.
Have you tried out Visual Studio 2008 yet? It has a LINQ to SQL classes template (a DataContext) that makes using stored procedures easy. The way I've been doing it is to create a class in the visual editor that has properties that map to the result set of a stored procedure. The stored procedure itself is added as a method of the DataContext that returns an IEnumerable<> of the class you created earlier. If you don't want to create the aforementioned class yourself though by default Visual Studio will generate a class for you that has properties that map to the result set, it'll be named the same as the stored procedure only ending with the word "Result". All of this is real similar to TableAdapters in Visual Studio 2005, which are still supported.
In your code you would use the DataContext with something like this:
TMSDataContext dc = new TMSDataContext();
DuplicateTimesheetHours[] dups = dc.CheckDuplicateTimesheetHours(fiscalYear, paymentType[0], payPeriod).ToArray();
April 24, 2008 at 9:57 am
Timothy,
Thanks for the instructions, I have not used Linq To SQL enough to have gotten to that point yet. I did know that you could use SP's for methods in Linq To SQL, but I had not gone behind the curtain to see how it was managed.
What I really meant about making using sp's easier is that when I use the VS 2008 designer and drag my tables onto the surface to create my classes, the default behavior is dynamic SQL for all queries and I then have to go in ansd change the behavior for CRUD operations. It would be nice to be asked if I want to use sp's at that point (I realize this could be difficult for many tables) and stepped through a wizard to select the sp's I want to use. Or, even better, Linq to SQL could create the sp's (even ask for the naming convention I want to use) for Insert, Update, Delete if I specify I want to use sp's for any or all of those operations. Now I get the ORM benefits and SP's for CRUD. I realize that for select's it would be very difficult, if not impossible, to use an SP with Linq to SQL because of the variations in SARG's , etc...
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
Viewing 15 posts - 31 through 45 (of 56 total)
You must be logged in to reply to this topic. Login to reply