Вы используете LINQ to SQL для новых проектов?

Question

Я изучал, какой уровень данных использовать для нового веб-проекта, который я разрабатываю, и я очень заинтересован в том, чтобы включить LINQ to SQL. Его очевидная простота, гибкость и поддержка дизайнеров действительно привлекательны, а скрытая привязка к SQL Server в порядке.

Тем не менее, недавно было объявлено, что LINQ to SQL займет заднее сиденье в Entity Framework теперь, когда оно было передано команде ADO.NET (http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx). Конечно, он будет поддержан в будущем, но маловероятно, что он увидит гораздо больше работ по разработке.

Имея это в виду, вы бы рекомендовали мне использовать эту технологию для моего проекта или стоит либо выбрать альтернативный ORM (nHibernate?), Либо вручную кодировать общий DAL?

Проект сам по себе является ASP.NET и SQL Server 2005/2008 и, возможно, будет использовать MVC, хотя он все еще находится в бета-версии. Это личный проект, база данных не будет чрезмерно сложной, и в основном она будет использоваться в качестве прототипа для изучения технологий .NET будущего. Я буду основывать будущие проекты на том, что я узнаю из этого, хотя, поэтому выбор, который я делаю, будет влиять на более крупные решения.

И да, я понимаю, что Microsoft, вероятно, в любом случае выведет совершенно новую технологию доступа к данным! ;)

Answer 1

Ну, это в основном покрыты ответы здесь (некоторые интересные точки зрения, а) уже, но я собираюсь сказать это снова в любом случае ..

LINQ к SQL (L2S) является очень гибким, но он чувствует себя слишком основательно с моей точки зрения. В большинстве случаев он хорошо справляется с простыми вещами, но как только вы попросите немного больше об этом, он становится дорогим. Это совсем не плохо. Я на самом деле думаю, что LINQ to SQL действительно приносит пользу Entity Framework.

Возьмите авто пейджинг с помощью LinqDataSource, например. Если вы не укажете Order By/Group, то это довольно экономично. Бросьте упорядочение или группировку в микс, и вы начинаете получать всплеск производительности (становится очень болтливым). Я бы сказал, что вам придется писать собственную реализацию подкачки (что, к сожалению, не очень сложно).

Я буду первым, кто признает, что L2S имеет преимущество перед Entity Framework с точки зрения качества сгенерированного T-SQL (я должен, поскольку L2S специально создан для запроса SQL Server) и концептуально и симпатично , большая часть LINQ to SQL похожа на EF, но там, где вы попадаете на стену, растут потребности и рассматриваются для более сложных требований к реализации.

Если бы я начал с нуля и решил посвятить личное время разработки, я бы выбрал Entity Framework. Интересно, что я работаю над проектом в тот момент, который использует L2S, и он предназначен для масштабирования над большими нагрузками, но когда мы сталкиваемся с некоторыми из более «креативных» требований, мы часто вынуждены расширяться на SQL Metal (например, отношения «многие ко многим»).

Так .. Короче .. Я бы подойти к нему так:

а) научиться LINQ к SQL как интро (для моделей ORM от Microsoft и технологии) ..он познакомит вас с большинством основ, которые разделяют с Entity Framework, и вкусом запроса стиля LINQ (приобретенный вкус, если у вас есть фон в T-SQL)

b) как только у вас есть обрабатывать LINQ to SQL, я бы рекомендовал перейти к Entity Framework, чтобы узнать дополнительные преимущества (eSQL и т. д.)

c) Внедрить доказательство концептуального проекта в обоих и сравнить результаты.

Answer 2

Выбрать NHibernate. Он будет оставаться в течение некоторого времени в качестве концепции или реального ORM. Так что полезно изучить оба.

Answer 3

L2S есть, ИМХО, отлично подойдет, так оно и есть, и, как вы уже сказали, никуда не денется. Корпорация, в которой я работаю, сделала ее стандартом для доступа к данным, и мы используем ее для всего, начиная от небольших приложений с нишевыми приложениями и заканчивая 1000-летними корпоративными приложениями с отличными результатами.

Answer 4

Заканчивать SubSonic:

http://subsonicproject.com/

Answer 5

Я думаю, что цели EDM наши намного больше, чем LINQ к SQL. Если вы ищете простой ORM, то я думаю, что LINQ to SQL - это путь. Если вы планируете строить классы, имеющие структуру наследования по отношению к таблицам базы данных, которые имеют реляционную структуру и выполняют другие расширенные сопоставления, тогда EDM может быть хорошим выбором.

Answer 6

ИМО, все это было действительно сдуло из пропорции.

Microsoft не сказала, что LINQ to SQL будет мертвым. Они указали, что они будут объединены в Entity Framework.

Я бы сосредоточился на использовании Entity Framework в качестве решения, зная, что большая часть LINQ to SQL будет свернута в него.

В любом случае, на самом деле это не так уж сильно. Самая большая жалоба заключается в том, что структура Entity Framework не является легкой. Это действительно имеет значение, если у вас есть хорошее разделение между уровнями?

Answer 7

Я согласен с Echostorm. L2S хорош для ваших нужд. И довольно легко работать с ...

Answer 8

Стоит отметить, что этот сайт построен с использованием LINQ to SQL. Джефф говорил об использовании этого в подкасте StackOverflow.

Answer 9

L2S - это потрясающая технология, и я никогда не вернусь к старой ADO.

Но, как вы уже упоминали, он берет заднее сиденье к L2E. L2S более чем способен, и я сделал множество приложений с ним и был невероятно доволен. Но, услышав, что он больше не будет продвинут, поставьте нож в мою сторону. Поэтому я пошел проверять L2E, и это почти то же самое, когда дело доходит до взаимодействия с SQL, и во многих отношениях мне становится проще, не говоря уже о более эффективном управлении отношениями. При таком сходстве логично выбрать L2E.

я написал пост о внесении переключателя и сравнении двух структур: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

Я могу почти гарантировать, что вы будете счастливы с любым из этих структур, они являются находкой для развития. Простота и предотвращение ошибок не имеют себе равных. Я лично склоняюсь к L2E, поскольку он будет развиваться более агрессивно, чем L2S.

Answer 10

Если вы правильно настроили приложение и изолировали свой уровень доступа к данным, вы должны пойти с L2S. Из того, что я делаю с вашего поста, это не большой проект, поэтому L2S должен удовлетворять вашим требованиям просто отлично, тогда как простой старый ADO.NET - это просто нет-нет, а Entity Framework - это ... просто не используйте его , ОК? В любом случае, если вы хорошо изолируете свой DAL, вы можете поменять L2S на что-то еще в будущем, если проект будет расти. и даже если L2S никуда не денется, он никуда не денется. MS прекратила инвестировать в нее, но она не станет устаревшей или что-то еще, поэтому она по-прежнему является надежной инвестицией. Кроме того, вы должны оценить NHibernate, который является простым и зрелым.

Answer 11

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

Прежде всего то, что вам нужно реализовать заранее, объекты DataContext предназначены для использования только до тех пор, пока единица измерения, период. Кроме того, DataContext не имеют гражданства. После того, как вы займетесь этими двумя принципалами, использование LINQ в среде n-уровня начнет работать хорошо.

С другой стороны, вы увидите, как многие люди рекомендуют использовать очень очень плохие способы использования Linq. Никогда не делайте свой DataContext статичным, это ошибка, которую я сделал на ранней стадии, и она творит чудеса, пока это не сработает, тогда это было абсолютно ужасно с неправильным переходом данных на разные сеансы и т. Д. Проще говоря, это, пожалуй, самый большой самый гигантский no-no из Linq и должен быть написан большими жирными буквами в каждом документе. Кроме того, сохранение DataContext в переменной Session является плохим решением.

Единственное другое серьезное противное, с которым я столкнулся с LINQ, - это когда вы делаете отключенное обновление, вам нужно использовать тот же DataContext для всего вызова. Например:

public static void UpdateUser(UserLibrary.User user) { 
     using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr)) 
     { 
      UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault(); 
      newUser.Email = user.Email; 
      newUser.FirstName = user.FirstName; 
      newUser.LastName = user.LastName; 
      dc.SubmitChanges(); 
     }   

Вы не можете просто передать пользователя, созданного в другом DataContext и ожидать обновления к работе, если вы установите DataContext.ObjectTrackingEnabled = ЛОЖЬ, что я бы не рекомендовал. Вместо этого в том же DataContext вы должны получить существующий объект, обновить его значения, а затем отправить эти изменения. Храните все похожие задачи в одном и том же DataContext.

Я бы порекомендовал L2S, хотя после того, как вы преодолеете несколько проблем с прикосновением (как, например, выше), это отличная технология и, безусловно, временная заставка. Тем не менее, я рекомендую сделать тонкую обертку вокруг вашего DAL, чтобы вы могли легко меняться. Я рассматриваю (по экономическим причинам) перенос части моего кода на использование OpenAccess ORM -> MySql для части моего доступа к данным и с правильно определенным уровнем, эта задача займет всего несколько часов.