Вопрос

Я изучал, какой уровень данных использовать для нового веб-проекта, который я разрабатываю, и мне очень хочется рассмотреть возможность включения 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 future.Однако я бы основывал будущие проекты на том, что я узнаю из этого, поэтому выбор, который я сделаю, повлияет на будущие более масштабные решения.

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

Это было полезно?

Решение

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

LINQ to 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 (напримеротношения "многие ко многим").

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

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

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

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

Другие советы

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

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

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

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

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

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

Проверьте дозвуковой:

http://subsonicproject.com/

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

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

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

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

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

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

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

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

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

Единственная другая серьезная проблема, с которой я столкнулся с 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 = false, что я бы не рекомендовал.Вместо этого в том же DataContext вы должны извлечь существующий объект, обновить его значения, а затем отправить эти изменения.Храните все похожие задачи в одном и том же DataContext.

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top