I echo what Charles has said exactly. Not to mention, the frameworks will support both EF and vanilla ADO and you can use linq or not. This gives the team an opportunity to learn new technology without needing to get deep into the grits of functionality the framework will do for you.
Tim


>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.
>