|
|
|
You haven't run out of cake have you?
|
|
|
|
|
I'll have the fish..... tastes of human sir.
|
|
|
|
|
The cake is a lie!
Proudly drinking the finest Maryland craft beer. Visiting Maryland for business? First round is on me!
|
|
|
|
|
It's a delusion, snare to trap the unwary, blot on the landscape etc. When I declare a variable I want to know what type it is, and I want to know why I cast it that way.
|
|
|
|
|
I'm still unsure about this. I have read about this in the "More Effective C#" book, but I'm not sure whether I agree with everything that is said. The only benefit I can see is that there is less code to type, and potentially less to change if you change a data type. I'm not sure that it makes the code more readable though. At the moment I use it often, but I'm having doubts about whether I should be using it.
|
|
|
|
|
The benefits are that you can work with anonymous types. It's pretty obvious. When it comes to using Linq you can create result-sets with just the values you want, rather than an entire entity:
<br />
var list = from person in db.Person<br />
where person.Dob < DateTime.Now.AddYears(-18)<br />
select new<br />
{<br />
person.PersonId,<br />
person.Name,<br />
person.Surname<br />
};<br />
Which will clearly make queries faster, and communication to SQL quicker (less data to bring back).
Once you have an anonymous type returned from a query, then iterating it thus makes sense:
<br />
foreach(var item in list)<br />
{<br />
Console.WriteLine(item.Name);<br />
Console.WriteLine(item.Surname);<br />
}<br />
Vars are local to the method's scope anyway, so if you don't know what the variable is then your method is far too complex and you should refactor.
I'm all for them. The 'dynamic' type coming in C# 4.0 is the one to worry about. That should in my opinion only be used for communication to non-typesafe resources (like COM, Javascript etc), and maybe used for dynamic fixup of events, methods and properties in things like ASP.NET, but that's all really.
|
|
|
|
|
Right, var is only for use with Linq. But you shouldn't use Linq either.
|
|
|
|
|
It isn't only used for Linq. It's useful for anonymous types, and if you so chose, to cut down on typing (I personally don't chose this, but there's nothing fundamentally wrong with it).
And why shouldn't you use Linq? A strongly typed method of interogating data-stores. Seems a pretty good idea to me. Also with the many-core world upon us, having features integrated into the language which can automatically parallelise is a no brainer.
|
|
|
|
|
OMG not use LINQ??? in which world are you living in? of course you have not ever used Entity Framework or .NET RIA Services, lol I feel pitty for the people out there that still uses SPs or similar old approaches for data management
|
|
|
|
|
NHibernate?
Proudly drinking the finest Maryland craft beer. Visiting Maryland for business? First round is on me!
|
|
|
|
|
chaosgeorge wrote: that still uses SPs
Linq works with stored procedures, doesn't it? (I don't use either.)
I feel pity for any who jump on the latest bandwagon. The old bandwagon is time-tested, tried and true.
|
|
|
|
|
Not really SPs are something and LINQ another although both are SQL at the end, and you can use SPs in LINQ too, the old bandwagon lacks of too many things addresed by new technologies, a lot of the mistakes committed by old bandwagons can be solved now with technologies like LINQ, I don't think your programming experience is any better with SPs than with LINQ
|
|
|
|
|
And yet Linq is just a layer atop ADO.net; I cut out the middleman and retain control.
|
|
|
|
|
So you're referring to LINQ to SQL or LINQ to Entities. But there's LINQ to Objects, LINQ to XML which are definitely valuable whatever you may think of the former.
Kevin
|
|
|
|
|
what control? I prefer a specilized middleman to make the hard work for me and focus on business saving time I feel more in control like that, and as the other post says LINQ is just a small part of a whole from object querying in all flavors to leverage data access technologies like entity framework or data services
|
|
|
|
|
chaosgeorge wrote: a specilized middleman
... of my own devising.
|
|
|
|
|
Why don't you write in assembler then? Cut out all the middle-men. Do you do all of your own memory management too? Because surely you don't trust the garbage collector and can implement it much better yourself?
Ludicrous argument. Language tools are there to make the process of programming easier, so we can develop larger, more complex and feature rich applications. It's that mentality of 'the old ways are the best' which makes developing large applications with blinkered team-members painful.
I'm not advocating jumping on every bandwagon. But where new language features come along which make the process of development more intuitive, then they should be considered. Linq is much more than an ADO.NET wrapper, and if you bother to read up on it you may realise that.
modified on Wednesday, August 19, 2009 2:12 PM
|
|
|
|
|
|
Title says all.
Until now, I didn't know that C# had a counterpart to VB.Net's "Object" type.
|
|
|
|
|
Fahad Sadah wrote: Until now, I didn't know that C# had a counterpart to VB.Net's "Object" type.
I don't know VB very well, but I don't think it is the same as the "Object" type. C# has an "Object" type, but "var" is different and should perform just as well as using the correct type.
|
|
|
|
|
The C# var and the VB var are two different things. The C# var is actually strongly typed. I find it useful for LINQ but that's about it.
-=} Randall {=- Musically speaking, C-Sharp is really D-flat
|
|
|
|
|
Another never, didn't know var existed.
I got curious and tried to lok it up in "The Complete Reference C# 2.0", and apparently it isn't complete. Index shows nothing for a "var" keyword.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
