Comments on: Getting to grips with LINQ 2.0 http://www.itwriting.com/blog/158-getting-to-grips-with-linq-20.html Tech writing blog Sun, 12 Feb 2012 05:28:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Kpac http://www.itwriting.com/blog/158-getting-to-grips-with-linq-20.html/comment-page-1#comment-104993 Kpac Thu, 07 Aug 2008 18:09:40 +0000 http://www.itwriting.com/blog/?p=158#comment-104993 Brian I think I just finished reading the follow up to that at http://www.linqhelp.com Brian I think I just finished reading the follow up to that at http://www.linqhelp.com

]]> By: Brian Lyttle http://www.itwriting.com/blog/158-getting-to-grips-with-linq-20.html/comment-page-1#comment-13057 Brian Lyttle Tue, 24 Apr 2007 18:57:05 +0000 http://www.itwriting.com/blog/?p=158#comment-13057 Nikhil Kothari from the ASP.NET team has already built something along the lines of the Google Web Toolkit http://projects.nikhilk.net/Projects/ScriptSharp.aspx I'm not entirely sure the world needs a lot more AJAX though. Usability, accessibility and performance are usually afterthoughts. I think these have traditionally been a problem for the ASP.NET community anyway. Regards LINQ and doing things the right way, I'd tend to agree with the sentiment but not with use of stored procs. Performance with a good OR/M tool like LLBLGen is as good or a little less than use of stored procs with much better productivity. In my experience it also reduces the pain for people upgrading your application. I guess best practice would say you should use Linq where you currently have your data access layer. Most of my app UIs only ever see custom objects, not datasets or the like. Some "very large scale applications" (eg. web 2.0 sites) have found a lot of drawbacks in relational databases - this is where LINQ V.Next may be looking. Google released an extension of the Hibernate framework that allows you to query shards of data that are spread across many servers (or [web]services). I could see Linq following along the same lines. I have no idea if this type of stuff is really going to be that useful for the majority of developers out there. esp. if your application data cannot traverse the company firewall, or you have limited support infrastructure/people to handle network outages. Nikhil Kothari from the ASP.NET team has already built something along the lines of the Google Web Toolkit http://projects.nikhilk.net/Projects/ScriptSharp.aspx

I’m not entirely sure the world needs a lot more AJAX though. Usability, accessibility and performance are usually afterthoughts. I think these have traditionally been a problem for the ASP.NET community anyway.

Regards LINQ and doing things the right way, I’d tend to agree with the sentiment but not with use of stored procs. Performance with a good OR/M tool like LLBLGen is as good or a little less than use of stored procs with much better productivity. In my experience it also reduces the pain for people upgrading your application.

I guess best practice would say you should use Linq where you currently have your data access layer. Most of my app UIs only ever see custom objects, not datasets or the like.

Some “very large scale applications” (eg. web 2.0 sites) have found a lot of drawbacks in relational databases – this is where LINQ V.Next may be looking. Google released an extension of the Hibernate framework that allows you to query shards of data that are spread across many servers (or [web]services). I could see Linq following along the same lines.

I have no idea if this type of stuff is really going to be that useful for the majority of developers out there. esp. if your application data cannot traverse the company firewall, or you have limited support infrastructure/people to handle network outages.

]]> By: Tim http://www.itwriting.com/blog/158-getting-to-grips-with-linq-20.html/comment-page-1#comment-7750 Tim Sat, 17 Mar 2007 09:31:09 +0000 http://www.itwriting.com/blog/?p=158#comment-7750 The jsc project is very interesting, thanks. Tim The jsc project is very interesting, thanks.

Tim

]]> By: zproxy http://www.itwriting.com/blog/158-getting-to-grips-with-linq-20.html/comment-page-1#comment-7749 zproxy Sat, 17 Mar 2007 08:26:37 +0000 http://www.itwriting.com/blog/?p=158#comment-7749 Yay! <blockquote> This would be transparent to the developer, because some intermediate piece would translate the .NET IL to JavaScript, or Java, or a Flash SWF. or somehing else. </blockquote> My <a href='http://jsc.sf.net' rel="nofollow">project jsc</a> does exactly this. :) Yet the jsc project is still in child shoes, but it really works. An early <a href='http://jsc.sourceforge.net/examples/web/LinqToObjects/fx.DemoControl.htm' rel="nofollow">LINQ to Objects</a> within jsc:javascript is also available. cheers Yay!

This would be transparent to the developer, because some intermediate piece would translate the .NET IL to JavaScript, or Java, or a Flash SWF. or somehing else.

My project jsc does exactly this. :)

Yet the jsc project is still in child shoes, but it really works.

An early LINQ to Objects within jsc:javascript is also available.

cheers

]]> By: Roger Jennings http://www.itwriting.com/blog/158-getting-to-grips-with-linq-20.html/comment-page-1#comment-7715 Roger Jennings Fri, 16 Mar 2007 19:08:21 +0000 http://www.itwriting.com/blog/?p=158#comment-7715 Thanks for the <a href="http://oakleafblog.blogspot.com/2007/03/20-in-early-returns-from-qcon-2007.html" rel="nofollow">eloquent review of Erik's keynote presentation</a>. --rj Thanks for the eloquent review of Erik’s keynote presentation.

–rj

]]> By: Clyde Davies http://www.itwriting.com/blog/158-getting-to-grips-with-linq-20.html/comment-page-1#comment-7710 Clyde Davies Fri, 16 Mar 2007 18:43:43 +0000 http://www.itwriting.com/blog/?p=158#comment-7710 Well, I'm open-minded about it. One thing that's very good about LINQ is that it brings relational concepts to client-side programming. Another database-originated feature I'd like to see on the client is proper support for transactions. Imagine how much easier it would be to write, say, an installer script for a package if you knew you were going to be targeting a transaction file system. :-) Well, I’m open-minded about it. One thing that’s very good about LINQ is that it brings relational concepts to client-side programming.

Another database-originated feature I’d like to see on the client is proper support for transactions. Imagine how much easier it would be to write, say, an installer script for a package if you knew you were going to be targeting a transaction file system. :-)

]]> By: Tim http://www.itwriting.com/blog/158-getting-to-grips-with-linq-20.html/comment-page-1#comment-7706 Tim Fri, 16 Mar 2007 17:53:06 +0000 http://www.itwriting.com/blog/?p=158#comment-7706 > The kind of bad practice I have in mind is where somebody puts > all the data access and business logic code in the client simply because > the development environment allows it. This is a longstanding problem with Microsoft's tools. But it's not inherent to LINQ that you would put the code in the wrong place. As for sprocs, that is another debate entirely :-) > The kind of bad practice I have in mind is where somebody puts
> all the data access and business logic code in the client simply because
> the development environment allows it.

This is a longstanding problem with Microsoft’s tools. But it’s not inherent to LINQ that you would put the code in the wrong place. As for sprocs, that is another debate entirely :-)

]]> By: Clyde Davies http://www.itwriting.com/blog/158-getting-to-grips-with-linq-20.html/comment-page-1#comment-7703 Clyde Davies Fri, 16 Mar 2007 17:38:26 +0000 http://www.itwriting.com/blog/?p=158#comment-7703 I have my severe doubts about some aspects of this LINQ approach. After having attended the MSDN Roadshow it struck me that LINQ might, in some cases, be encouraging bad practice. The kind of bad practice I have in mind is where somebody puts all the data access and business logic code in the client simply because the development environment allows it. Where I work, if we are developing a large database application we put as much business logic and data access code as close to the data storage as possible, in stored procedures. It's easier to maintain, much better performing (as optimisations can be done with reference to the underlying data) and generally more robust. I suppose we will just have to wait and see how it all works out. I have my severe doubts about some aspects of this LINQ approach. After having attended the MSDN Roadshow it struck me that LINQ might, in some cases, be encouraging bad practice. The kind of bad practice I have in mind is where somebody puts all the data access and business logic code in the client simply because the development environment allows it.

Where I work, if we are developing a large database application we put as much business logic and data access code as close to the data storage as possible, in stored procedures. It’s easier to maintain, much better performing (as optimisations can be done with reference to the underlying data) and generally more robust.

I suppose we will just have to wait and see how it all works out.

]]>