Как вы думаете, выгодно ли переходить на Entity Framework?
С LINQ to SQL, скорее всего, не будет так много активной разработки, как Entity Framework. Как вы думаете, лучше ли переходить на Entity Framework?
Лично я обнаружил, что EF очень неуклюжий и сложный в использовании по сравнению с LINQ to SQL, который кажется очень естественным.
РЕДАКТИРОВАТЬ: я недавно опубликовал статью в своем блоге о моих чувствах к этому потенциальному решению...
8 ответов
ИМО, не сейчас.
Ясно (особенно из недавних анонсов), что EF ожидает серьезных изменений, поскольку сценарий " грома " разворачивается между LINQ-to-SQL и EF. Что бы ни случилось, EF (через несколько лет) почти наверняка будет выглядеть совсем не так, как EF сегодня. Или, конечно, "достаточно разные";-p
Таким образом, мое мнение таково: придерживайтесь простого. И просто LINQ-to-SQL.
Я не вижу большой пользы в изучении заведомо сложной системы, если знаю, что она очень скоро изменится.
И я на 100% с вами на LINQ-to-SQL;-p
Если бы мне сейчас понадобилось нечто большее, чем LINQ-to-SQL, я бы посмотрел на NHibernate или, может быть, LLBLGen Pro.
(изменить - в качестве обновления моя позиция немного смягчилась здесь и здесь - но я все еще использую LINQ-to-SQL в качестве основного инструмента; также - LINQ-to-SQL еще не совсем мертв; - п).
Я выполнил несколько проектов MVC, которые сейчас находятся в производстве с использованием L2SQL, и нашел, что им очень приятно пользоваться. Сейчас я начинаю новый проект и решил написать его, используя EF и L2EF, учитывая ранее цитированные статьи, провозглашающие смерть L2SQL. Спустя всего пару дней я решил вернуться к L2SQL. Простые вещи, такие как необходимость установки внешних ключей для вставок с использованием либо ужасного синтаксиса, показанного ниже, либо ненужные поиски, потрясли меня.
foo.Foreign_TypeReference.EntityKey =
new EntityKey("DataContextName.Foreign_Type", "Foreign_Type_Id", ForeignTypeId);
Скорее, чем:
foo.Foreign_Type_Id = ForeignTypeId;
Я не думаю, что будет трудно портировать L2SQL на будущую версию EF, поскольку L2SQL имеет подмножество функциональных возможностей (хотя и лучше реализованных). Несколько вещей, которые есть в L2SQL, которых нет в L2EF, например Single() и SingleOrDefault(), можно перенести в EF, создав несколько методов расширения. Я думаю, что потребуется гораздо меньше времени для запуска системы с использованием L2SQL, а затем перенести ее позже, когда EF не так вонючий.
Если вы занимаетесь разработкой на основе баз данных, у EF сегодня есть реальные преимущества.
Я использовал как LINQ to SQL, так и EF и преодолел множество маленьких разочарований в EF v1.
Тем не менее, одна вещь, которая сделала EF v1 победой для меня, это удивительно хорошее обновление от мастера баз данных. Невероятно, но это действительно работает! Это может показаться тривиальным, но если вы занимаетесь проектированием на основе базы данных, вы хотите полагаться на инструменты для создания ваших классов и не хотите заново создавать всю модель, чтобы внести изменения.
Уже одно это делает EF v1 моим выбором. Я предлагаю не обращать внимания на расширенные возможности EF v1 - он еще далеко не пригоден для использования, хотя и является амбициозной платформой, к которой он стремится.
Смирись с неповоротливостью EF v1, и ты будешь в лучшем положении на будущее.
Пит.
Я должен согласиться с Марком Гравеллом. Возможно, когда будет выпущена следующая версия Entity Framework (.net 4.0 / VS2010), будет ли преимущество в использовании EF, и к тому времени она, вероятно, будет сильно отличаться от текущей версии EF.
До тех пор, по крайней мере, я буду избегать EF, как чумы для всего, кроме тестов / экспериментального кода, который никогда не попадет в производство.
Форум EF msdn полон примеров того, почему EF не готов к прайм-тайму, но есть один конкретный пример, который является явным победителем - обычно это простой запрос из пяти таблиц (10-15 строк SQL) становится >1500 строк SQL при использовании EF и элемента управления EntityDataSource:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3874607&SiteID=1
http://paste-it.net/public/q6ed5c2/
А что касается будущего EF - с учетом того, что Microsoft в одночасье меняет направление на крупные стратегические вещи, кто знает, сбудется ли их текущая "стратегическая цель" с EF через пару лет? Я бы точно не поспорил на это. Увидеть:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4100399&SiteID=1
LINQ to SQL, похоже, не подходит, если вы не используете SQL Server (или SQL Server compact), поэтому для меня было достаточной причиной, чтобы избежать этого и использовать EF (я хотел использовать PostgreSQL).
В v1 EF определенно не хватает вещей, которые заставили бы меня смущаться рекомендовать это. Похоже, что версия 2 EF (после выпуска) будет первой версией, которую можно было бы серьезно рекомендовать для перехода на.
Напомним, что некоторые колебания относительно будущего LINQ to SQL были выражены здесь:
Многие опытные разработчики дали " ADO.NET Entity Framework вотум недоверия", что обсуждается здесь далее.
Я думаю, мы ожидаем, что он будет значительно улучшен в .Net 4.0 командой ADO.Net.
А вот немного видео с недавнего PDC.
Недавно мне пришлось исследовать, какой проект ORM следует использовать. Сначала - попробовал L2S. Это было совсем не плохо, но уже устарело (MS больше не будет его поддерживать), поэтому я начал проверять L2E. Я в порядке с сгенерированным кодом, но создание поддельных представлений, сущностей и отображений между ними просто для того, чтобы сделать хранимую процедуру доступной, чтобы не заполнять все поля сущностей, было для меня излишним. И я хотел отделить свой слой доступа к данным, поэтому мне пришлось сопоставить данные из сгенерированных объектов с теми, которые я создал.
Мне потребовалось несколько часов, чтобы поэкспериментировать с NHibernate+Fluent NHibernate+LINQ to NHibernate
придерживаться этой комбинации.