С LINQ to SQL, скорее всего, не будет так активно развиваться, как Entity Framework, вы считаете, что лучше переключиться на Entity Framework?
Я лично нашел, что EF очень неуклюж и трудный в использовании по сравнению с LINQ to SQL, который кажется очень естественным.
EDIT: Недавно я опубликовал статью в своем блоге о своих чувствах к этому потенциальному решению...
IMO, а не на данный момент.
Ясно (от недавних анонсов, особенно), что EF находится под некоторыми серьезными изменениями как " thunderdome" между LINQ-to-SQL и EF. Что бы ни случилось, EF (через несколько лет) почти наверняка будет сильно отличаться от EF сегодня. Или, конечно, "достаточно разные"; -p
Таким образом, мое мнение: придерживаться простого. И простой LINQ-to-SQL.
Я не вижу большой пользы в изучении печально сложной системы, если я знаю, что она скоро изменится.
И я на 100% с вами на LINQ-to-SQL; -p
Если мне сейчас нужно что-то большее, чем LINQ-to-SQL, я бы посмотрел на NHibernate или, возможно, LLBLGen Pro.
(edit), в качестве обновления моя позиция немного смягчилась, здесь и здесь - но я все еще использую LINQ-to-SQL в качестве основного инструмента, а также - LINQ-to-SQL еще не совсем мертв;-p).
Я закончил несколько проектов 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 forum содержит примеры того, почему 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:
LINQ to SQL, похоже, не является вариантом, если вы не используете SQL Server (или SQL Server compact), поэтому мне достаточно было избежать этого и использовать EF (я хотел использовать PostgreSQL).
В v1 EF явно не хватает вещей, которые заставили бы меня порекомендовать его. Это похоже на версию 2 EF (когда она была выпущена) будет первой версией, которая может быть серьезно рекомендована для перехода на.
Довольно много опытных разработчиков дали " ADO.NET Entity Framework Vote of No Confidence", как обсуждается далее здесь.
Я думаю, мы ожидаем, что он значительно улучшится в .NET 4.0 командой ADO.Net.
И вот некоторые видео из недавнего PDC.
Недавно мне пришлось исследовать, какой проект ORM должен использовать. Сначала - попробовал L2S. Это было неплохо, но это уже устарело (MS больше не будет его поддерживать), поэтому я начал проверять L2E. Я в порядке с сгенерированным кодом, но создание поддельных представлений, сущностей и сопоставлений между ними просто для того, чтобы сделать хранимую процедуру доступной, чтобы не заполнять все поля сущности, было для меня излишним. И я хотел отделить свой уровень данных, так что - мне пришлось сопоставлять данные из сгенерированных объектов с теми, что я сделал.
Мне потребовалось несколько часов экспериментов с NHibernate + Fluent NHibernate + LINQ to NHibernate
придерживаться этой комбинации.