Entity Framework 4 против родного Ado.net

Question

Мне было интересно, как Entity Framework 4 сравнивается с нативными Ado.Net и SP?

что бы мне не хватало, если бы я использовал обычный Ado.Net?

стоит ли покидать EF4?

Answer 1

Короче говоря, EF - это объектно-реляционный картограф (ORM), а ADO.Net - это необработанная мощь.ORM позволяет вам торговать некоторой производительностью во время выполнения для простоты обслуживания.Вы получаете возможность писать код более декларативным образом, выражая что вы хотите из базы данных, а не точно как получить его.В результате, изменения в структуре базы данных могут быть учтены в сопоставлениях, а не в каждой части вашего приложения, которая должна была касаться конкретной таблицы, которая изменилась.

Чего вам не хватало бы, если бы вы использовали ADO.Net - продуктивность разработчика.Подробное описание каждой операции с базой данных в ADO.Net отнимает много времени, подвержено ошибкам и не доставляет особого удовольствия.

Не думаю, что мне когда-нибудь захочется "оставить" ORM и вернуться к сырому ADO.Net, за исключением ситуаций, когда требуется чрезвычайная производительность, например, при импорте больших объемов данных, в этом случае вам, возможно, будет лучше написать пакет служб SSIS.

Answer 2

EF не подходит для "обработки" больших объемов данных: например, статистических или финансовых данных с большим количеством абстрактных объектов.В противном случае это нормально.Во всяком случае, если вы не страдаете от проблем с производительностью - это тоже хорошо.Кроме того, ничто не мешает вам использовать оба понятия одновременно.

Answer 3

EF кажется более естественным, но если вы хардкорный пользователь SQL, поначалу он может казаться слабым и странным. Но мне нравится делать все на стороне c #, меньше проблем с обслуживанием, меньше головной боли, меньше волшебных строк.

В любом случае, из-за проблем с производительностью, если вы не делаете массовые вставки, обновления, вы не увидите никакой разницы.

Если вы используете обычный ADO.Net, без какого-либо OR / M, обернутого вокруг него, вы все равно будете работать с записями, а не с классами с поведением и методами. Вам понадобится дополнительный слой biz, привязанный к записи.