>>But, I truly believe that old school "SQL" with command objects, datasets, datatables and datarows and all that code is way more difficult than EF and LINQ. In EF you set your new values and then call SaveChanges. I don't know what's easier than that.


Actually, I agree with your manager, but I'd go further.
I'm using typed datasets and datables, but I started my first C# apps using 100% SQL passthru,- no databinding, no datasets, zilch. Just executequery and executenonquery.

Just datables filled with executequey and all the updates were done by passing parametes to stored procedures with executenonquery. I populated the values of all the UI controls myself and retrieved them myself.
Sounds awfully primitive doesn't it?
Well, it worked better that way and I was a lot more productive.
I'll stay with datasets because more clients want them, but if it were my choice I'd got back to the zilch approach.

Performance wise, the zilch approach is hands down faster - you're running at native SQL server speed with no other overheard,
You can't get faster than that, period.

Regarding development time, if you factor in all the waiting I have to do every time I modify a form while all those datasets and data tables and adapters set themselves up, I've lost days in development time just watching an hour glass.

Try it on a complex form that uses a lot of datatables .. there are tens of thousands of lines of code that have to be referenced every time you change anything significant and sooner or later that has a price.

I doubled the RAM in my computer because of it, but it's still a lot slower than working with a from without all that overhead.

There are numerous undocumented bugs in the databinding model. I just spent two days locating an undocumented bug in the datetimepicker binding that wiped out all the bindings on the form with no warning message. Once I isolated the control, I found a workaround on Google but that's not a rare occurrence, so factor in that nonsense while thinking about the time you'll save.

Regarding, EF.. MS changes the flavor of the month capriciously. I invested months in Linq-to-SQL and now it's dead meat.

Based on history native C# will be alive and healthy, but, WPF and EF will both be toast 3 years from now and your manager should be getting a good raise for avoiding that grief.

He won't get any prizes from any tech organizations, but he'll be a good manager.

Tell him I said so!
:)


.





.


>>We are a FoxPro 9 shop that needs to move to C# or we could lose our contract with our one customer.

I know C#, but am a beginner. I've written a number of ASP.NET apps and my first one was in 2003 and I wrote my own Data Access Layer using old school command object, parameters, datasets, datatables and datarows. It was a lot of work.

Sine then I've used Mere Mortals and have enjoyed the fact that the BO Generator writes the DAL and the fields in tables become strongly typed class fields/properties and the Intellisense kicks in.

And I've been studying the new EF in .NET Framework 4.0.

So, in our programming meeting yesterday I was demo'ing LINQPad and the whole concept of LINQ. Well, practically everyone flipped out saying it was too hard and that they wouldn't have time to learn it. Well, for starters none of them even know C#, so they've got a huge learning curve ahead of them regardless.

Then the manager stated that we wouldn't use LINQ and instead we would resort to old school using SQL. Well, the manager doesn't know C# either, but his philosophy was "we all need to be able to support each other's applications" and we need to keep it simple enough to that if you get hit by a bus... I call this the least common denominator mode of team programming.

But, I truly believe that old school "SQL" with command objects, datasets, datatables and datarows and all that code is way more difficult than EF and LINQ. In EF you set your new values and then call SaveChanges. I don't know what's easier than that.

Opinions?

[View the first child message of this message]