Вы бы использовали LINQ to SQL для новых проектов? - PullRequest
9 голосов
/ 24 декабря 2008

Я изучал, какой слой данных использовать для нового веб-проекта, который я проектирую, и мне очень интересно взглянуть на включение LINQ в 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, вероятно, завтра все равно выпустит совершенно новую технологию доступа к данным! ;)

Ответы [ 11 ]

7 голосов
/ 24 декабря 2008

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

4 голосов
/ 06 января 2009

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

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

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

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

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

Итак .. короче .. я бы подошел к этому так:

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

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

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

4 голосов
/ 24 декабря 2008

ИМО, вся эта штука была действительно раздута.

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

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

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

2 голосов
/ 05 мая 2009

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

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

С другой стороны, вы увидите множество людей, рекомендующих некоторые очень и очень плохие способы использования Linq. НИКОГДА не делайте ваш DataContext статичным, это ошибка, которую я сделал на раннем этапе, и она творит чудеса, пока она не работает, тогда это было абсолютно ужасно с неправильным пересечением данных между различными сессиями и т. Д. Проще говоря, это, пожалуй, самая большая самое гигантское нет-нет использования 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.ObjectTrackingEnabled = false, что я бы не рекомендовал. Вместо этого в том же DataContext вы должны извлечь существующий объект, обновить его значения, а затем отправить эти изменения. Храните все похожие задачи в одном DataContext.

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

2 голосов
/ 06 января 2009

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

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

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

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

2 голосов
/ 24 декабря 2008

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

2 голосов
/ 24 декабря 2008

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

2 голосов
/ 24 декабря 2008

Проверьте SubSonic:

http://subsonicproject.com/

2 голосов
/ 24 декабря 2008

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

1 голос
/ 06 января 2009

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

...