|
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.
|
|
|
|
|
|
Ah, so I'm antiquated using 2.0...
(and having a hard time getting .NET 2.0 installed on various production systems that barely have .NET 1.1!)...
|
|
|
|
|
CDMTJX wrote: having a hard time getting .NET 2.0 installed on various production systems that barely have .NET 1.1!
And .NET 4 will be out in a couple of months perhaps! 
Kevin
|
|
|
|
|
funny 
|
|
|
|
|
C# does indeed have a counterpart to VB.Net's Object type. It's called object, or System.Object. And var is different to both of those. It's effectively syntactic sugar, which is replaced with the correct, strictly bound method type name upon compilation.
Between the motion
And the act
Falls the Shadow
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
