Поскольку LINQ to SQL, скорее всего, не получит такой активной разработки, как Entity Framework, как вы думаете, лучше всего перейти на Entity Framework?
Я лично обнаружил, что EF очень неуклюжий и сложный в использовании по сравнению с LINQ to SQL, который кажется очень естественным.
РЕДАКТИРОВАТЬ: Я недавно разместил в своем блоге статью о своих чувствах к этому потенциальному решению ...
ИМО, на данный момент нет.
Это ясно (из особенно недавние объявления), что EF подвергается серьезным изменениям, так как "thunderdome" сценарий разыгрывается между 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).
Я завершил несколько проектов 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 не готов к выходу в прайм-тайм, но есть один конкретный пример < / a> это явный победитель - то, что обычно было бы простым запросом из пяти таблиц (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 были выражены здесь:
Действительно ли Microsoft убила LINQ to SQL?
LINQ to SQL, похоже, не подходит, если вы не используете SQL Server (или SQL Server compact), поэтому для меня это было достаточной причиной, чтобы избежать этого и использовать EF (я хотел использовать PostgreSQL).
В v1 EF определенно не хватает вещей, поэтому я не решусь рекомендовать его. Похоже, что версия 2 EF (когда она будет выпущена) будет первой версией, которую можно серьезно рекомендовать для перехода на.
Немало опытных разработчиков предоставили "ADO .NET Entity Framework: вотум недоверия ", как подробно обсуждается здесь.
Я думаю, мы ожидаем его значительного улучшения в . Net 4.0 командой ADO.Net.
А вот несколько видео с недавнего PDC.
Недавно мне пришлось исследовать, какой проект ORM следует использовать. Сначала - попробовал L2S. Это было неплохо, но оно уже устарело (MS его больше не поддерживает), поэтому я начал проверять L2E. Меня устраивает сгенерированный код, но создание поддельных представлений, сущностей и сопоставлений между ними только для того, чтобы сделать хранимую процедуру доступной, чтобы не заполнять все поля сущности, было для меня излишним. И я хотел отделить свой слой доступа к данным, поэтому мне пришлось сопоставить данные из сгенерированных объектов с теми, которые я создал.
Мне потребовалось несколько часов экспериментов с NHibernate + Fluent NHibernate + LINQ to NHibernate
, чтобы придерживаться этой комбинации.
