Какой у вас был опыт работы с Entity Framework?

РЕДАКТИРОВАТЬ (да, 3 года спустя) ... Я больше не ненавижу EF ... Entity Framework 4.1 и выше великолепен - он (наконец) решает все проблемы / недостатки, которые у него были в прошлом. Обратите внимание, что не «4.0», а «4.1», наконец, устранили уродливое использование «волшебных строк» ​​и т. д. В нем есть Contains и все остальное, плюс еще.

Ниже мой старый комментарий от 2008 года.

Лично я ненавижу EF. Я ЛЮБЛЮ LINQ-2-SQL. Вот мои конкретные предупреждения об EF:

1) EF не поддерживает функцию «Содержит». Итак, если у вас есть таблица из 10 000 «учетных записей», и вы хотите вернуть несколько учетных записей, для которых пользователь предоставил список идентификаторов ... вам придется загрузить все 10 000 и выполнить цикл for.

2) EF не поддерживает отложенную загрузку: http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx

3) Если у вас есть простая таблица типа, например AccountType ... и вы хотите выбрать все учетные записи из таблицы Accounts, где AccountTypeID == 9, в EF нет чистого способа сделать это в EF ... EF будет скрыть это поле и заставить вас предоставить экземпляр класса AccountType.

Все эти проблемы решены в L2S.

Обновлено: О, вы спросили «каковы ваши впечатления ...» не только о проблемах. В моей новой работе у них есть база данных из 205 таблиц, более 600 хранимых процедур и т. д. Я хотел восполнить пробел в новый мир программирования ... поэтому я преобразовал DAL в 1-1 "перетащить все таблицы внутрь" версия с использованием EF. Вот как это выглядело: Гигантский EDM

Спустя всего 1 неделю мне пришлось вырвать его и заменить на L2S из-за проблем, о которых я упоминал выше, и некоторых других.

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

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

Получить помощь сложно

Другая неприятная часть EF заключается в том, что куда бы вы ни пошли за помощью, там полно фанатиков L2S, которые думают, что они уже знают все, что вам нужно делать, и продолжают пытаться сказать вам, чтобы вы бросили это и просто использовали L2S ... Если бы я попросил как это сделать в L2S, тогда, может быть, их мнение будет справедливым ...

EF отлично работает

Хорошо работает базовая способность создавать объекты, которые затем можно расширить с помощью частичных методов. На самом деле я был очень расстроен на ранних этапах, потому что продолжал пытаться получить то же, что и в SQLCommand. Как только вы поймете, что можете думать о том, что нужно бизнес-логике, а не о том, как работает SQL, вы сможете сделать гораздо больше.

Например, я все время пытался делать объединения, чтобы получить список вещей, которые были связаны определенным FK для различных задач. Как только я, наконец, понял, что могу передать все это где-то в EF и дать понять, как быстро вернуть мне данные, код на самом деле стал намного быстрее.

Включает вонь

Хотя синтаксис Include мне кажется хакерским. Необходимость использовать .Include ("TableName.DetailTable") УЖАСНО. Может быть, intellisense меня просто избаловал, но я ненавижу этот синтаксис.

По запросу нагрузки

Загрузка основных деталей также немного уродлива. Если вы не хотите включать их, вы всегда можете взять их ссылку и посмотреть, есть ли у нее .IsLoaded, а затем вызвать .Load. Почему? Разве объект не может сделать это за меня? В итоге я реализовал метод расширения для своих объектов, который, если я попытаюсь загрузить незагруженный класс деталей, он загрузит его по запросу. Похоже, это должно было быть встроено в меня.

Примечание. Подробная загрузка отфильтрованного набора записей, упомянутого в вышеупомянутом сообщении, не сложна, но и неочевидна. Вы можете фильтровать, используя лямбда-выражения.

Вы КОГДА-ЛИБО хотите переместить проект?

Вот основная причина: отсутствие привязки к поставщику. Если вы КОГДА-ЛИБО хотите перенести этот код в другую базу данных, вы НЕ МОЖЕТЕ сделать это с Linq2SQL. Нет модели провайдера. У вас может быть возможность перенести систему EF к другому поставщику. В моем случае один и тот же проект работает на SQL Server и VistaDB EF (Alpha) без изменения кода. Так что я могу развернуть его xcopy или подключиться к серверу по своему усмотрению во время выполнения.

После тестирования EF для нового проекта (ASP.Net/ WCF) я обнаружил:

Запросы очень легко реализовать через LINQ. Большую часть времени сгенерированный T-SQL был прибыльным.

Поддержка N-уровневых приложений практически отсутствовала.

Управление экземплярами в контексте объекта было столь же болезненным в n-уровневых приложениях asp.net.

EF Designer не хватало некоторых очевидных функций, всегда погружался в XML.

Обновления требуют либо дорогостоящих обращений к базе данных, либо содержат безумно непонятные методы, позволяющие избежать их.

Падение производительности было значительно заметно при использовании многоуровневого приложения на основе POCO & SP. Это было ожидаемо, но не настолько, насколько мы заметили. Даже после составления запросов.

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

Как коснулся Брэйн, обращение к типу сущности или имени таблицы по строке сильно раздражало и выглядело очень беспорядочно, я обнаружил, что пишу обертки, чтобы возвращать их из одной точки.

Если вы хотите использовать однослойное приложение, многие из проблем, с которыми мы столкнулись, могут не применяться.

Но что касается нас, мы внимательно следим за V2 и, надеюсь, некоторыми улучшениями.