Считаете ли вы, что переход на Entity Framework выгоден?

ИМО, на данный момент нет.

Ясно (особенно из последние объявления), что 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 еще не совсем мертв ;-p).

Довольно много опытных разработчиков дали "ADO .NET Entity Framework: вотум недоверия", как обсуждается далее здесь.

Я думаю, мы ожидаем, что команда ADO.Net значительно улучшит его в .Net 4.0.

А вот и видео с недавнего PDC.

Для записи, некоторые сомнения относительно будущего LINQ to SQL были выражены здесь:

Является ли LINQ to SQL DOA?

Неужели Microsoft убила LINQ to SQL?

Я должен согласиться с Марком Гравеллом. Может быть, когда будет выпущена следующая версия 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#4107623

LINQ to SQL, похоже, не подходит, если вы не используете SQL Server (или SQL Server compact), поэтому для меня это было достаточной причиной, чтобы избежать этого и использовать EF (я хотел использовать PostgreSQL).

В v1 EF определенно не хватает вещей, поэтому я не решаюсь рекомендовать его. Похоже, что версия 2 EF (когда она будет выпущена) будет первой версией, которую можно серьезно рекомендовать для перехода на.

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

Я использовал LINQ to SQL и EF и преодолел множество мелких разочарований, связанных с EF v1.

Однако единственное, что заставило меня победить EF v1, - это потрясающе хороший мастер обновление из базы данных. Невероятно, но это действительно работает! Это может показаться тривиальным, но если вы проектируете сначала базу данных, вам нужно полагаться на инструменты для создания классов за вас, и вам не нужно регенерировать всю свою модель только для того, чтобы внести изменения.

Одно это делает мой выбор EF v1. Я предлагаю игнорировать расширенные функции EF v1 - он еще далеко не пригоден для использования как амбициозная платформа, к которой он стремится.

Смиритесь с неуклюжестью EF v1, и в будущем вы будете в лучшем положении.

Пит.

Я завершил несколько проектов 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 не будет таким вонючим.

Недавно мне пришлось исследовать, какой проект ORM следует использовать. Сначала - попробовал L2S. Это было неплохо, но оно уже устарело (MS его больше не поддерживает), поэтому я начал проверять L2E. Меня устраивает сгенерированный код, но создание фальшивых представлений, сущностей и сопоставлений между ними только для того, чтобы сделать хранимую процедуру доступной, чтобы не заполнять все поля сущности, было для меня излишним. И я хотел отделить свой слой доступа к данным, поэтому мне пришлось сопоставить данные из сгенерированных объектов с теми, которые я создал.

Мне потребовалось несколько часов экспериментов с NHibernate + Fluent NHibernate + LINQ to NHibernate
. придерживаться этой комбинации.