Каков ваш опыт работы с Entity Framework? - PullRequest
9 голосов
/ 30 ноября 2008

EF уже давно отсутствует, и я подумываю оценить его - каков был ваш опыт?

Меня интересуют как веб-приложения, так и приложения для настольных компьютеров, а также, возможно, некоторые сравнения между EF и другими инструментами ORM, которые вы использовали.

Кривая обучения является фактором, так как в нем участвует команда. Является ли эта вещь раздутым беспорядком или она скудная и острая?

Я слышал, что Microsoft использует это внутренне и широко, так что это хороший знак. Если у вас есть какие-либо мысли о том, как это может вписаться в облачное будущее, что MS, похоже, тратит свои деньги в эти дни, это также может быть интересно. В конце концов, если это то, что нам всем в конечном итоге понадобится , чтобы знать, это повысило бы уровень приоритета на ступеньку или две.

Большое спасибо!

Ответы [ 3 ]

6 голосов
/ 04 декабря 2008

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

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

Получение справки является грубым

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

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

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

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

Включает вонючий

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

По требованию нагрузки

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

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

Вы когда-нибудь хотите перенести проект?

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

1 голос
/ 13 февраля 2009

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

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

В основном отсутствовала поддержка приложений N-уровня.

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

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

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

Производительность значительно возросла в приложении n / tier на основе POCO & SP. Это ожидалось, но не в той степени, в которой мы заметили. Даже после компиляции запросов.

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

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

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

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

1 голос
/ 01 декабря 2008

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: О, вы спрашивали "каков ваш опыт ...", а не только о проблемах. В моей новой работе у них есть база данных из 205 таблиц, более 600 хранимых процедур и т. Д. Я хотел преодолеть пробел в новом мире программирования ... поэтому я преобразовал DAL в 1-1 "перетащить все таблицы" версия с использованием EF. Вот как это выглядело: Гигантский EDM

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...