LINQ vs. .netTiers

I am not familiar with LINQ so I was wondering how it differs from .netTiers. Any comments are appreciated.

Hello,

Linq is different than NetTiers in a few ways. First it requires .Net 3.5 while NetTiers uses .Net 2.0. Linq also uses various .Net 3.0 features, the Linq syntax (similar to TSQL) is compiled / parsed into pretty optimized SQL queries, and it’s worth noting that you can have Linq use existing stored procedures. I like to think of Linq as being more dynamic, elegant, and easier to use than stored procedures (which NetTiers uses).

I would recommend reading the following document which explains Linq in more detail from the prospective of a NetTiers user migrating to Linq (http://www.giannim.com/2007/11/26/linq-coming-from-nettiers-part-1/).

Thanks

-Blake Niemyjski

Having used both LINQ and NetTiers, I have a mildly differing opinion. LINQ to objects is all about Query - it works equally well against NetTiers objects, Active Directory, Lists, or any IEnumerable object. The entity classes that can be created as a byproduct of LINQ to SQL similar to the lower level NetTiers data classes, assuming you don't do any validation or custom service functions. If you do, you have to add that framework yourself to the LINQ to SQL generated classes. NetTiers can be used to simply generate Table-to-Objects equivalents like LINQ to SQL. But once you get past that simple surface functionality, NetTiers offers a more robust framework.

Doni

I did alot of research on some ideas that i really wanted to see in the next version of Nettiers.  One that I looked at since it is the new technology of the day was Linq.  One thing I quickly noticed is that this will not work in a disconnected Tiered environment.  You have to use the very same data context in which you retrieved the data in order to update the data.  People that use Web Services or Remoting would just be out of luck when it came to using an Entire Linq solution (using Linq to hit Sql).

The classes that hold the data from the Linq Entity framework are very limited.  There are no original values, no Accept, reject changes.  These are features that I don't know too many nettiers users would live without.  Most people that migrated to using Nettiers were probably making the move from Datasets or recordsets.  Alot of code is written to look at Entity State and other IComponentModel features.

I love writing new code in new technology, as a pretty hard core developer, I always think that way.  But I also like to give new technology a little time to see if it works in an enterprise wide scenario.  So many times Microsoft will come out with all these samples that take 30 seconds to implement a linq to Sql webpage that has a list and details that I can edit.  But when you try to Architect this in an N-Tier environment, those 30 second demos go out the door.  I like Nettiers because it fits in any of these scenarios.  It is layered in it's own since.  You can use the data Layer, the Business Layer, the ASP controls, the WinForm controls all together or you can piece mail them together.

Anyway, Linq is yet another thing for all architects to consider.  That's what's so fun about our profession, always new things to keep you challenged and excited about being a programmer.

jeff

I'm still getting to know Linq's capabilities, but from what I've seen, I tend to agree with your comments. Linq has a few aspects to it. I can see XLinq being useful and the querying aspect of in-memory collections is powerful too. The only element I think that doesn't add value in a nettiers environment is the Linq to SQL part.