I've always used direct data access for dealing with objects in the past (manually running a query, and mapping the results into data objects). I know Microsoft is currently pushing EF for their customers to use for querying data objects.
I've got a few questions for the community in respect to this :-
If you have a complex database, i.e. a couple of hundred tables, a decent amount of stored procedures, views, everything is in 3NF. Is the burden of managing two schemas (one local EF schema mapping and one DB) worth the trade off?
Once you start to ramp up the data access, how does caching compare on the two? I know in Direct access you can implement any form of caching you want, does EF allow something similar?
Given Microsoft's history of killing off products after heavily pushing them and getting people to write for them (SQL-NS, Linq-to-Sql) how likley is this to happen to EF?
As I said I'm currently heavily using Direct Access at the moment, but considering a migration (i.e with new queries going forward, not backtracking on them all just yet), and was looking for advice from the rest of the community on their views.
If you have a complex database, i.e. a couple of hundred tables, a decent amount of stored procedures, views, everything is in 3NF. Is the burden of managing two schemas (one local EF schema mapping and one DB) worth the trade off?
You can use automated tools to keep your EF schema up-to-date, so it's not really that bad.
Once you start to ramp up the data access, how does caching compare on the two? I know in Direct access you can implement any form of caching you want, does EF allow something similar?
As far as I know, yes.
Given Microsoft's history of killing off products after heavily pushing them and getting people to write for them (SQL-NS, Linq-to-Sql) how likley is this to happen to EF?
This question is far too hypothetical.
The issue I'm having with EF is it's performance. Yea, you get rapid development, but trading off performance. With EF it's really easy to write a bad and slow code and if you don't 100% know what you're doing, you may end up with some serious performance issues later on (especially if you're dealing with hundreds of tables).
What I'd suggest is to try some Micro-ORM frameworks, like Dapper or Massive. You don't sacrifice that much performance, but it's easier to maintain than traditional Ado.net approach.
But hey, that's just me, you may love EF.