You like tools, do you? ;-)

I completely agree. What I always ask people who want to roll their own, or think tools "cost too much money," is if they seriously think they can develop equivalent functionality (leaving aside the question of whether they are capable of that) for a few hundred dollars worth of labor. I know I can't. The people who develop these tools are better than I will ever be. It would be vain or foolish of me not to stand on their shoulders.

I would love to order DevBlade right now. Unfortunately that's going to have to wait for a paying customer to fund it.

>Go to Ideablade.com and do yourself the favor of learning what EF is really all about. (Actually its seems your instincts about it are good - it's your pointy headed boss that needs educating)
>
>Frameworks are the best investment a team can make,
>
>Bill's advice may work exactly as he says it does for him, but the idea of doing a complex app that way would terrify me. It's like the days when people got VFP then wrote FPDOS-like code directly against tables in 2 tier apps and were astounded they had problems later on networks and WANs and in moving to a SQL backend.
>
>At very least look at Julia Lerman's stuff on MSDN, Code Magazine etc re EF.
>
>WPF is a whole lot easier with some basic training ( Pluralsight, Learndevnow.com ) and a whole lot faster with stuff like DevExpress.
>
>If you're not going with WPF and really like to stick with straight sql check out what Strataframe or MereMortals brings to the table. If your team doesn't already know *about* Linq and finds it scarey you've got some people who *need* the structure of a framework that takes care of things they don't even know are issues.
>
>"Roll your own" is exactly the wrong approach for a group like this. Get some help from the framework builders that have been dealing with this stuff for 10 years now while they've been programming in Foxpro.
>
>
>
>>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?