Missing LINQ?
-
Is anybody else more than just a little uneasy about LINQ? The few examples I've seen make no sense to me. And I can't see what drove them to this solution either. I picture somebody at MS saying "ya know, let's take this well known standardized perfectly good query language that everybody is used to, chuck it out the window, and make a cryptic bizzare syntax built into the language itsef..." Ok, I can see some advantages to having it built it to the languages, not least of all avoiding the need for string storage and manipulation. But could it not have been more... SQL-like? Am I alone here or does anybody else have reservations about LINQ? And I know there are some people out there that are really excited about it, I'd like to hear what they have to say too.
Try code model generation tools at BoneSoft.com.
You've made very little attempt to understand LINQ. However, the great thing about it is you never have to use it. You can happily continue in your blissful ignorance. The more enlightened among us will eagerly start leveraging the power and flexibility of being able to query RDMS, file and memory object data sources simultaneously, all with the effeciency of IDE and compiler support. We will shave off the many man-hours lost in 'debugging' in shoddy database management and scripting tools as we cruise along on a great layer of abstraction, increasing our productivity and competitive edge by several orders of magnitude. Resistance to change is common to the human condition, but I hope that you will overcome your unwillingness to learn a little extra syntax. Frankly, I'm convinced that LINQ is the natural evolution from the the mediocre-success attempts at object databases and object persistence frameworks that we've seen from various companies (e.g CodeGear ECO & DevExpress PO - both of which I have the utmost respect for). If you really wanna grasp this LINQ stuff, I suggest you watch the video of Charlie Calvert and Anders Hejlsberg explaining and discussing it in some depth. You can Google it. I hope it'll bring a little clarity and insight. You've gotta understand that SQL only does half the job. Generally, a developer does this: 1. Create a database in the RDMS 2. Write SQL queries, test them against the RDMS and store them somewhere (code, SP etc) 3. In the application write code to connect to RDMS and pass the raw SQL 4. Receive the raw data results from the RDBMS 5. Convert the results to code objects for manipulation in the application 6. Implement controls & code for the user to work with the data LINQ halves the steps and reduces the process to: 1. Create a database in the RDMS 2. Write LINQ queries within IDE 3. Implement controls & code for the user to work with the data What a pleasure! Less cumbresome donkeywork and the same results and performance. Brilliant! Plus I get to query a whole bunch of other stuff (even combine the queries) and not have to worry about loading, drivers, query translation. Man, I think I'm getting a woodie... Note that you use wizards in the IDE to establish a framework for your LINQ queries (it connects to the RDMS and automatically generates code objects that the LINQ queries will work with).
-
Is anybody else more than just a little uneasy about LINQ? The few examples I've seen make no sense to me. And I can't see what drove them to this solution either. I picture somebody at MS saying "ya know, let's take this well known standardized perfectly good query language that everybody is used to, chuck it out the window, and make a cryptic bizzare syntax built into the language itsef..." Ok, I can see some advantages to having it built it to the languages, not least of all avoiding the need for string storage and manipulation. But could it not have been more... SQL-like? Am I alone here or does anybody else have reservations about LINQ? And I know there are some people out there that are really excited about it, I'd like to hear what they have to say too.
Try code model generation tools at BoneSoft.com.
I think you are assuming that LINQ is solely intended to be a SQL replacement which it is not. It is meant to be (yet another) layer of abstraction that allows you to interact with the query related aspects of databases, XML, DataSets and even your business objects in a common fashion. I have no special love for M$ and tend to agree with the other posts that we should wait and see how the final (or second) version turns out, but I think we may find it to be a useful tool. The use of attributes on class and property names is very similar to what I do to simply query generation and sproc parameter passing in my own code. Having something like that built into the framework (or is it technically a langugue feature?) should be nice. I have found that the main project page has some good information.
Josh Fischer
-
Clickok wrote:
.Net Framework is here since 2002 and it isn't neither nice or usable...
I'd have to disagree with that. I'm very happy with it. And I'm looking forward to the enhancements in 2008.
Upcoming FREE developer events: * Glasgow: db4o: An Embeddable Database Engine for Object-Oriented Environments, Mock Objects, SQL Server CLR Integration, Reporting Services ... My website
LINQ is sweet. It allows you to drag and drop tables and stored procedures onto a work surface that causes objects to be built that will interface with the database. Can you say business objects? You can then take those objects and drop them on a form and create either multiple entry (grid) or single entry representations of the tables. You can then display table data and update it back in the database without writing any code. Fairly complex data binding can be accomplished by editing properties on the fields. The business objects can have code added to them that reflects business logic. Acropolis is nice and Silverlight 1.1 is really nice and will run anywhere when the Moonlight version is complete. -- modified at 8:41 Tuesday 25th September, 2007
Len
-
You've made very little attempt to understand LINQ. However, the great thing about it is you never have to use it. You can happily continue in your blissful ignorance. The more enlightened among us will eagerly start leveraging the power and flexibility of being able to query RDMS, file and memory object data sources simultaneously, all with the effeciency of IDE and compiler support. We will shave off the many man-hours lost in 'debugging' in shoddy database management and scripting tools as we cruise along on a great layer of abstraction, increasing our productivity and competitive edge by several orders of magnitude. Resistance to change is common to the human condition, but I hope that you will overcome your unwillingness to learn a little extra syntax. Frankly, I'm convinced that LINQ is the natural evolution from the the mediocre-success attempts at object databases and object persistence frameworks that we've seen from various companies (e.g CodeGear ECO & DevExpress PO - both of which I have the utmost respect for). If you really wanna grasp this LINQ stuff, I suggest you watch the video of Charlie Calvert and Anders Hejlsberg explaining and discussing it in some depth. You can Google it. I hope it'll bring a little clarity and insight. You've gotta understand that SQL only does half the job. Generally, a developer does this: 1. Create a database in the RDMS 2. Write SQL queries, test them against the RDMS and store them somewhere (code, SP etc) 3. In the application write code to connect to RDMS and pass the raw SQL 4. Receive the raw data results from the RDBMS 5. Convert the results to code objects for manipulation in the application 6. Implement controls & code for the user to work with the data LINQ halves the steps and reduces the process to: 1. Create a database in the RDMS 2. Write LINQ queries within IDE 3. Implement controls & code for the user to work with the data What a pleasure! Less cumbresome donkeywork and the same results and performance. Brilliant! Plus I get to query a whole bunch of other stuff (even combine the queries) and not have to worry about loading, drivers, query translation. Man, I think I'm getting a woodie... Note that you use wizards in the IDE to establish a framework for your LINQ queries (it connects to the RDMS and automatically generates code objects that the LINQ queries will work with).
Frobro wrote:
You've made very little attempt to understand LINQ
Thanks Mr. Obvious, I'm glad you caught what was plainly spelled out for you. That was a well established fact from the initial post, and reiterated throughout the thread.
Frobro wrote:
You can happily continue in your blissful ignorance. The more enlightened among us... blah blah blah
And I appreciate the personal attack oh enlightened one, may Budha be with you too. But I must admit, after that introduction I didn't bother to read the rest of your Post. Maybe later today. Cheers :)
Try code model generation tools at BoneSoft.com.
-
Is anybody else more than just a little uneasy about LINQ? The few examples I've seen make no sense to me. And I can't see what drove them to this solution either. I picture somebody at MS saying "ya know, let's take this well known standardized perfectly good query language that everybody is used to, chuck it out the window, and make a cryptic bizzare syntax built into the language itsef..." Ok, I can see some advantages to having it built it to the languages, not least of all avoiding the need for string storage and manipulation. But could it not have been more... SQL-like? Am I alone here or does anybody else have reservations about LINQ? And I know there are some people out there that are really excited about it, I'd like to hear what they have to say too.
Try code model generation tools at BoneSoft.com.
Finally, another one who has the wisdom to ask the question, "Do we really need a new query language for data access in .NET?"... The answer is no!!! ORM software and other such tools like LINQ do nothing to increase the efficiency of data access in .NET applications. In fact, they make it worse by adding yet another "layer of abstraction" into our work which also increases maintenance overhead. As one technician said earlier this year, if you want to work with object related to your data acces than use an object-oriented database. ORM software, though an interesting concept, is a waste of time for both the technicians to learn and the applications to use.
Steve Naidamast Black Falcon Software, Inc. blackfalconsoftware@ix.netcom.com
-
Is anybody else more than just a little uneasy about LINQ? The few examples I've seen make no sense to me. And I can't see what drove them to this solution either. I picture somebody at MS saying "ya know, let's take this well known standardized perfectly good query language that everybody is used to, chuck it out the window, and make a cryptic bizzare syntax built into the language itsef..." Ok, I can see some advantages to having it built it to the languages, not least of all avoiding the need for string storage and manipulation. But could it not have been more... SQL-like? Am I alone here or does anybody else have reservations about LINQ? And I know there are some people out there that are really excited about it, I'd like to hear what they have to say too.
Try code model generation tools at BoneSoft.com.
Enters the MS Fan Boy Old Man: LINQ Yes.. LINQ Yes.. ?? LINQ is not just another data layer tool or some technology to destroy n-tier model as some seem to think. It is not just some toy for play. Microsoft has a much larger picture with LINQ which is basically a unified approach at searching, managing, grouping and ordering data no matter what form it takes. Does not matter if it is a simple array in memory, an XML file or a database, data is handled very much the same way allowing to understand one technology to cover all those different needs. Unification is the goal and LINQ is the answer. Many developers do not see the big picture and still think that you would only use LINQ every now and then. I use it often! My data layer is built on LINQ and internal business objects are handled by LINQ along with global internal application data that I need to search or organize. If there is a collection of data, there I will be with my LINQ queries. With LINQ it is a simple task to deal with data that is relational or heirarchical such as XML. It allows me to deal with data as objects and build new objects out of data. The LINQ 2 SQL is pretty cool but you have to watch out that you do not get bit by a large number of hits to the database, but can be managed with a little care. LINQ 2 SQL can take a lot of the work out of the databse handling if you trust in it to do the work for you. To start with, I approached it much like ADO.NET and building out Sprocs for most of the work, but found that LINQ 2 SQL does a fairly good job (and I expect even better in the future versions) generating everything that is needed without all the extra developer time to do it. It can handle some complicated queries (nested joins and groupings) without much effort. One of the first stumbling blocks in LINQ is the syntax. It is much like learning a new SQL language and many tend to fight learning something new. The first error is to approach LINQ as you would SQL, they are quite different beasts. As an example, you comment that you think the query is backwards, but really, once you are use to the syntax, you think SQL is backwards :) That is the point, you need to approach it with an open mind and be flexible. After just a couple of weeks, a developer should be confortable and enjoy the time savings from use LINQ all over the place. I still advice keeping the database access portion in a data layer abstracted from the rest of the application, but it does do a decent job at generating objects
-
Scott Dorman wrote:
Right now there isn't anyone at Microsoft focused specifically on LINQ and getting the word out about it.
I don't know... Daniel Moth, one of the UK's DPEs, has done quite a good job in some of his presentations. http://www.danielmoth.com/Blog/2007/02/decomposing-linq.html[^] Skip to the last code sample to see what it looks like without LINQ. Daniel has got quite a good series of blog posts on LINQ. I've also got some information on LINQ and some of the new language constructs in C# 3.0: * Anonymous Types[^] * Method Extensions[^] * Automatic Properties[^] * A start on LINQ[^] * Object Initialisers I[^] * Object Initialisers II[^] * Object Initialisers III[^]
Upcoming FREE developer events: * Glasgow: db4o: An Embeddable Database Engine for Object-Oriented Environments, Mock Objects, SQL Server CLR Integration, Reporting Services ... My website
Well said! Here is a link to Part 9 of Scott Guthrie's blogs on new 2008 features. The part 9 post contains links to the previous 8 parts. http://weblogs.asp.net/scottgu/archive/2007/09/07/linq-to-sql-part-9-using-a-custom-linq-expression-with-the-lt-asp-linqdatasource-gt-control.aspx[^]
-
Is anybody else more than just a little uneasy about LINQ? The few examples I've seen make no sense to me. And I can't see what drove them to this solution either. I picture somebody at MS saying "ya know, let's take this well known standardized perfectly good query language that everybody is used to, chuck it out the window, and make a cryptic bizzare syntax built into the language itsef..." Ok, I can see some advantages to having it built it to the languages, not least of all avoiding the need for string storage and manipulation. But could it not have been more... SQL-like? Am I alone here or does anybody else have reservations about LINQ? And I know there are some people out there that are really excited about it, I'd like to hear what they have to say too.
Try code model generation tools at BoneSoft.com.
-
I pretty much agree with all the points made above. I have been playing around with LINQ for quite a while now and can see big benefits from having a set of features that allow you to query several different data types/structures using one common syntax. Yes it takes a little getting used to but don't all new languages/code implementations. Surely good practice as a coder dictates that you should understand the technologies and workings of the code you are implementing? On this basis I definatly agree that the methods/classes underlying this new feature set should be taught and explained as to grasp more fully the under the hood workings and to not be led blindly down an alley. I do have major revisions with LINQ however so far from my playing. The technology seems to be totally inadequate for a multi tier environment. Take a simple n tier environemnt, database, data layer, business layer, ui layer. For the data layer you create LINQ classes to query your data structures. Take this simple senario, your UI has a button that calls a method contained in your business layer, for example User.Login(). When this method is called you want your business layer to make a call to your data layer using LINQ. When you write the code in your business layer you use the new annonymous type keyword, var, to create a smaller subset of your customer object. for example:
var _Cust = from c in DataLayer.Customers where c.UserName = "Some Name" and c.Password = "Password" select new {c.UserId, c.FirstName, c.Surname}So, in the senario above we have used projection to create a new annonymous type, which is a great complier trick on MS part. This saves us creating many different methods to return different data collections/structures for the same object etc. We can create them on the fly and loop through them etc. However here comes the point were it all comes unstuck as far as i can tell. We now want to return our new type to the UI layer so that we can use the data it contains to bind to our presentation layer. Pretty normal senario you would say, but guess what, you cannot return a annonymous data types from a method!!!! So a method trying to return a var data type will not compile. This to me seems totally crazy, microsoft give us this great power of type projection with some really neat compiler trickery but then prevent us from returning it from any of our methods which to me makes it un-usable in any n-tier system. Yes use it in a single layer in a void method but thats about all folks. How doYeah, that's disturbing to hear. I may have to investigate it some to see if there is a way around that. Like I said in the initial post, a lot of people seem to be really excited about it. So I assume there are good points of interest.
Try code model generation tools at BoneSoft.com.
-
The reason Linq looks wierd is that, to get intellisense to work, they had to but the "subject" of the query in front. So, with DLinq, it's the table name. Otherwise intellisense wouldn't be able to help the lazybones programmer figure out the columns associated with the table. Marc
It's almost a bit disturbing that they would base language design decisions on IDE requirements. But then again, language design can be based on lots of things, and in some ways I'm complaining about it's aesthetics.
Try code model generation tools at BoneSoft.com.
-
BoneSoft wrote:
But could it not have been more... SQL-like?
Ummm - it pretty much *is* SQL, apart from the ordering of the statement clauses? This example off Wikipedia looks quite SQL-ish to me.
var q = from o in db.Orders, c in db.Customers
where o.Quality == "200" && (o.CustomerID == c.CustomerID)
select new { o.DueDate, c.CompanyName, c.ItemID, c.ItemName };The other thing to remember is that LINQ is generalized across *anything*, so long as it implements the appropriate interface or methods. This makes it incredibly easy to perform operations on collections of objects, rather than having to loop over them. This feature is just one part of the migration into C# of features normally found in functional programming languages - type inference, lambdas, LINQ (pretty much equivalent to list comprehensions). Now, if they could work out how to safely add lightweight processes and message passing a la Erlang, .NET languages would really be in a good position to make good use of multicore chips. Of course, so long as you have shared, mutable state, you're always going to be in a position to have 'interesting' threading bugs.
True enough, that does look like mangled SQL. Maybe the inital examples that were out when I first started looking at it weren't the best.
Try code model generation tools at BoneSoft.com.
-
Enters the MS Fan Boy Old Man: LINQ Yes.. LINQ Yes.. ?? LINQ is not just another data layer tool or some technology to destroy n-tier model as some seem to think. It is not just some toy for play. Microsoft has a much larger picture with LINQ which is basically a unified approach at searching, managing, grouping and ordering data no matter what form it takes. Does not matter if it is a simple array in memory, an XML file or a database, data is handled very much the same way allowing to understand one technology to cover all those different needs. Unification is the goal and LINQ is the answer. Many developers do not see the big picture and still think that you would only use LINQ every now and then. I use it often! My data layer is built on LINQ and internal business objects are handled by LINQ along with global internal application data that I need to search or organize. If there is a collection of data, there I will be with my LINQ queries. With LINQ it is a simple task to deal with data that is relational or heirarchical such as XML. It allows me to deal with data as objects and build new objects out of data. The LINQ 2 SQL is pretty cool but you have to watch out that you do not get bit by a large number of hits to the database, but can be managed with a little care. LINQ 2 SQL can take a lot of the work out of the databse handling if you trust in it to do the work for you. To start with, I approached it much like ADO.NET and building out Sprocs for most of the work, but found that LINQ 2 SQL does a fairly good job (and I expect even better in the future versions) generating everything that is needed without all the extra developer time to do it. It can handle some complicated queries (nested joins and groupings) without much effort. One of the first stumbling blocks in LINQ is the syntax. It is much like learning a new SQL language and many tend to fight learning something new. The first error is to approach LINQ as you would SQL, they are quite different beasts. As an example, you comment that you think the query is backwards, but really, once you are use to the syntax, you think SQL is backwards :) That is the point, you need to approach it with an open mind and be flexible. After just a couple of weeks, a developer should be confortable and enjoy the time savings from use LINQ all over the place. I still advice keeping the database access portion in a data layer abstracted from the rest of the application, but it does do a decent job at generating objects
Point taken. And I eventually will look into it. I have to look at all language enhancements to see if there is benifit in it for me, and of course so I can read other's code as well. I can see how a flawed perspective (assuming primarily a SQL replacement) could affect my view of LINQ. I'll have to look into it's other uses as well.
Try code model generation tools at BoneSoft.com.
-
MY main interest is the possibility of dealing with XML directly in code, instead of having to deal with strings and XML api's. The rest seems a bit odd - like SQL but not exactly :confused: JP
XML is the one thing I doubt I'll use LINQ for. I've grown too attached to my serialization. I don't rely on strings and the DOM API either, serialization serialization serialization. One of the best (and fairly overlooked) innovations of the framework from 1.0 on.
Try code model generation tools at BoneSoft.com.
-
Frobro wrote:
You've made very little attempt to understand LINQ
Thanks Mr. Obvious, I'm glad you caught what was plainly spelled out for you. That was a well established fact from the initial post, and reiterated throughout the thread.
Frobro wrote:
You can happily continue in your blissful ignorance. The more enlightened among us... blah blah blah
And I appreciate the personal attack oh enlightened one, may Budha be with you too. But I must admit, after that introduction I didn't bother to read the rest of your Post. Maybe later today. Cheers :)
Try code model generation tools at BoneSoft.com.
BoneSoft wrote:
I didn't bother to read the rest of your Post. Maybe later today.
I'd recommend reading its post. I found it quite well written considering it's coming from a troll. ;) Regards, BDF
-
XML is the one thing I doubt I'll use LINQ for. I've grown too attached to my serialization. I don't rely on strings and the DOM API either, serialization serialization serialization. One of the best (and fairly overlooked) innovations of the framework from 1.0 on.
Try code model generation tools at BoneSoft.com.
SO how do you work with multiple etherogeneous xml sources from external suppliers or customers where you want to cherry pick information from? Would you have to recreate all their object/data models? I can do that with standard WebServices (VS does that for me), but the majority of them have plain xml interfaces (no automatic object model creation). We currently deal with it using XML Api. Previously we used to use xsl, but xsl syntax is too dense, making it dificult for other people to analyse. JP
-
SO how do you work with multiple etherogeneous xml sources from external suppliers or customers where you want to cherry pick information from? Would you have to recreate all their object/data models? I can do that with standard WebServices (VS does that for me), but the majority of them have plain xml interfaces (no automatic object model creation). We currently deal with it using XML Api. Previously we used to use xsl, but xsl syntax is too dense, making it dificult for other people to analyse. JP
I've rarely needed to cherry pick details from XML, and in that scenario LINQ sounds like a great alternative. Because otherwise you'd have no real alternative but to use the DOM. Serialization would be gross overkill for that, I'll concede. A couple of years ago I was working for a company that ran a travel web site. They pulled all their information from several different sources, all XML, and virtually none were proper web services. I wound up writing my own tools to create XML serializable models from XML & XSD because I hated what XSD.exe produced. Once the tool was done, I could take their HUGE XML structures and create programmable entity classes in seconds. Effectively shaving months of work off in seconds. I dunno, maybe LINQ would be a more appealing solution for some. Currently other than XSD.exe, which sucks, I'm not aware of too many tools out there that generate serializable code from XML/XSD structures. XSL might be an interesting idea for transforming different models to a standard model, but XSL is a really gross language to deal with. I bet that took a lot of time and work.
Try code model generation tools at BoneSoft.com.
-
You've made very little attempt to understand LINQ. However, the great thing about it is you never have to use it. You can happily continue in your blissful ignorance. The more enlightened among us will eagerly start leveraging the power and flexibility of being able to query RDMS, file and memory object data sources simultaneously, all with the effeciency of IDE and compiler support. We will shave off the many man-hours lost in 'debugging' in shoddy database management and scripting tools as we cruise along on a great layer of abstraction, increasing our productivity and competitive edge by several orders of magnitude. Resistance to change is common to the human condition, but I hope that you will overcome your unwillingness to learn a little extra syntax. Frankly, I'm convinced that LINQ is the natural evolution from the the mediocre-success attempts at object databases and object persistence frameworks that we've seen from various companies (e.g CodeGear ECO & DevExpress PO - both of which I have the utmost respect for). If you really wanna grasp this LINQ stuff, I suggest you watch the video of Charlie Calvert and Anders Hejlsberg explaining and discussing it in some depth. You can Google it. I hope it'll bring a little clarity and insight. You've gotta understand that SQL only does half the job. Generally, a developer does this: 1. Create a database in the RDMS 2. Write SQL queries, test them against the RDMS and store them somewhere (code, SP etc) 3. In the application write code to connect to RDMS and pass the raw SQL 4. Receive the raw data results from the RDBMS 5. Convert the results to code objects for manipulation in the application 6. Implement controls & code for the user to work with the data LINQ halves the steps and reduces the process to: 1. Create a database in the RDMS 2. Write LINQ queries within IDE 3. Implement controls & code for the user to work with the data What a pleasure! Less cumbresome donkeywork and the same results and performance. Brilliant! Plus I get to query a whole bunch of other stuff (even combine the queries) and not have to worry about loading, drivers, query translation. Man, I think I'm getting a woodie... Note that you use wizards in the IDE to establish a framework for your LINQ queries (it connects to the RDMS and automatically generates code objects that the LINQ queries will work with).
Ok, I read it... After your condescension, the colorful imagery of surfing on another abstraction layer, the gross exageration of "several orders of magnitude", and your missguided assumption that my apprehension to jump on the band wagon equates to an "unwillingness to learn a little extra syntax" that can only come from a lack of "clarity and insight", all you really said was that you don't have to work with SQL and can access other data sources in the same manner. My point is just that SQL's never been a problem for me, and XML serialization will probably still be a more appealing approach to dealing with XML for me. But I enjoyed the "what a developer does" 101 course. While we're pointing out each others "problems", I'd say yours is assuming that I'm some dumb ass that doesn't understand all this icky development stuff. Here's my 101 course for you: When discussing something, if you want someone to see your point of view, talking down to them or worse belittling them is the fastest way to get people to stop listening to what you have to say and automatically discount anything you say. Which "is common to the human condition." If you'll notice, most people responding to this thread, dispite their view, courteously keep their responses in the tone of a peer. Showing that they don't automatically assume they are superior. And... query translation? When did you deal with that? I'd love to get my hands on a SQL parser, you wanna write an article and share?
Try code model generation tools at BoneSoft.com.
-
BoneSoft wrote:
I didn't bother to read the rest of your Post. Maybe later today.
I'd recommend reading its post. I found it quite well written considering it's coming from a troll. ;) Regards, BDF
I appreciate the recommendation. But his couple of points were made by nicer people. :-D
Try code model generation tools at BoneSoft.com.
-
Is anybody else more than just a little uneasy about LINQ? The few examples I've seen make no sense to me. And I can't see what drove them to this solution either. I picture somebody at MS saying "ya know, let's take this well known standardized perfectly good query language that everybody is used to, chuck it out the window, and make a cryptic bizzare syntax built into the language itsef..." Ok, I can see some advantages to having it built it to the languages, not least of all avoiding the need for string storage and manipulation. But could it not have been more... SQL-like? Am I alone here or does anybody else have reservations about LINQ? And I know there are some people out there that are really excited about it, I'd like to hear what they have to say too.
Try code model generation tools at BoneSoft.com.
What got me excited about LINQ was a post I read somewhere where they were talking about PLINQ, where some of the LINQ queries are automatically parallelized to take advantage of multi-core environments. It made the point that performaing that optimization was possible with LINQ because you tell the compiler what you want to accomplish, not what steps to take to accomplish that.
-
What got me excited about LINQ was a post I read somewhere where they were talking about PLINQ, where some of the LINQ queries are automatically parallelized to take advantage of multi-core environments. It made the point that performaing that optimization was possible with LINQ because you tell the compiler what you want to accomplish, not what steps to take to accomplish that.
Yeah, that sounds interesting. A step beyond connection pooling. Good point.
Try code model generation tools at BoneSoft.com.