Должен ли я начать использовать LINQ To SQL?

Question

В настоящее время я использую NetTiers для создания уровня доступа к данным и уровня обслуживания. Я использую NetTiers уже более 2 лет и считаю, что это очень полезно. В какой-то момент мне нужно взглянуть на LINQ, поэтому мои вопросы ...

1. Кто-нибудь еще переходил с NetTiers на LINQ To SQL?
2. Этот переключатель был хорошим или плохим?
3. Есть что-нибудь, о чем я должен знать?
4. Вы бы порекомендовали этот переключатель?

В принципе, я бы приветствовал любые мысли .

Answer 1

1. Нет
2. См. # 1
3. Вам следует остерегаться стандартных накладных расходов на абстракцию. Кроме того, это очень SQL Server в его текущем состоянии.
4. Вы используете SQL Server, тогда, возможно. Если вы сейчас используете LINQ для других целей, таких как данные XML (отлично), данные объектов, наборы данных, то да, вам следует переключиться на единый синтаксис данных для всех них. Как упомянуто lagerdalek , если оно не сломано, не почините. Из быстрого взгляда на .netTiers Application Framework я бы сказал, что если у вас уже есть инвестиции в это решение, оно, похоже, даст вам гораздо больше, чем простой уровень доступа к данным, и вам следует придерживаться его.

Исходя из моего опыта, LINQ to SQL является хорошим решением для небольших и средних проектов. Это ORM, который является отличным способом повышения производительности. Он также должен дать вам еще один уровень абстракции, который позволит вам заменить слой под чем-то другим. Дизайнер в Visual Studio (и я верю VS Express) очень прост и удобен в использовании. Он дает вам общее перетаскивание и редактирование сопоставлений объектов на основе свойств.

@ Джейсон Джексон - Дизайнер позволяет добавлять свойства вручную, однако вам нужно указать атрибуты для этого свойства, но вы делаете это один раз, это может занять 3 минуты дольше, чем первоначальное перетаскивание таблицы в конструктор, однако это необходимо только один раз для каждого изменения в самой базе данных. Это не слишком отличается от других ORM, однако вы правы в том, что они могут сделать это намного проще, и находят только те свойства, которые изменились, или даже реализуют какой-то инструмент рефакторинга для таких нужд.

Ресурсы:

• Зачем использовать LINQ to SQL?
• Скотт Гатри в LINQ to SQL
• 10 советов по повышению производительности приложений LINQ to SQL
• Обновление производительности LINQ To SQL и Visual Studio 2008
• Сравнение производительности LINQ to SQL / ADO / C #
• LINQ to SQL 5-минутный обзор

Обратите внимание, что Parallel LINQ разрабатывается для обеспечения гораздо большей производительности на многоядерных машинах.

Answer 2

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

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

Изучите LINQ to SQL серии Скотта Гатри постов в блоге для некоторых замечательных примеров того, как его использовать.

Answer 3

NetTiers очень хороши для создания тяжелого и надежного DAL, и мы используем его для внутренних библиотек и сред.

На мой взгляд, LINQ (во всех его воплощениях, но, в частности, так как я думаю, что вы спрашиваете SQL) отлично подходит для быстрого доступа к данным, и мы обычно используем его для более гибких случаев.

Обе технологии довольно негибки для изменения без регенерации кода или слоя dbml.

Как говорится, использование LINQ 2 SQL - достаточно надежное решение, и вы можете даже начать использовать его для будущей разработки из-за его простоты использования, но я бы не стал отказываться от вашего текущего DAL - если это не сломался ...

Answer 4

Наша команда использовала NetTiers и нашла это полезным. НО ... чем больше мы его использовали, тем больше у нас возникали головные боли и болевые точки. Например, каждый раз, когда вы вносите изменения в базу данных, вам необходимо заново сгенерировать DAL с помощью CodeSmith, который включает:

• воссоздание тысяч строк кода в 3 отдельных проектах
• воссоздание сотен хранимых процедур

Может быть, есть другие способы сделать это, но это то, что мы должны были сделать. Регенерация исходного кода была в порядке, страшно, но хорошо. Настоящая проблема возникла с хранимыми процедурами. Он не очищал неиспользуемые хранимые процедуры, поэтому, если вы удалили таблицу из своей схемы и заново сгенерировали DAL, хранимые процедуры для этой таблицы не были удалены. Кроме того, это стало настоящей головной болью для сценариев изменения базы данных, где нам пришлось сравнивать старую структуру базы данных с новой и создавать сценарий изменения для обновления установок клиента. Этот скрипт может работать с десятками тысяч строк SQL-кода, и если при его выполнении возникла проблема, которая неизменно возникала, решить ее было довольно сложно.

Затем загорелся свет, NHibernate как ORM. У него, конечно, есть время нарастить, но оно того стоит. Существует масса поддержки для этого, поэтому, если вам нужно что-то сделать, скорее всего, это было сделано раньше. Он чрезвычайно гибкий и позволяет вам контролировать каждый его аспект, а затем и некоторые. Это также становится все легче и проще в использовании. Fluent Nhibernate - это отличный способ избавиться от необходимых файлов сопоставления xml, а NHibernate Profiler предоставляет отличный интерфейс для наблюдения за тем, что происходит за кулисами, для повышения эффективности и устранения избыточности.

Переход с NetTiers на NHibernate был болезненным, но хорошим способом. Это заставило нас перейти к лучшей архитектуре и пересмотреть функциональные потребности. NetTiers предоставили тонны кода доступа к данным, получили эту сущность по ее идентификатору, получили эту другую сущность по внешнему ключу, получили tlist и vlist того и того, но большинство из них было ненужным и неиспользованным. NHibernate с общим хранилищем и пользовательскими хранилищами только там, где это необходимо, сокращает тонны неиспользуемого кода и действительно повышает удобочитаемость и надежность.

Answer 5

Я сейчас использую LINQ to SQL для довольно большого проекта (около 150 таблиц), и он работает очень хорошо для меня. Последним ORM, который я использовал, был IBatis, и он работал хорошо, но потребовалось немало усилий, чтобы сделать ваши отображения. LINQ to SQL работает очень хорошо для меня, и до сих пор оказалось очень простым в использовании из коробки. Определенно есть некоторые различия, которые вы должны преодолеть при переходе, но я бы порекомендовал его использовать.

Примечание: я никогда не использовал и не читал о NetTiers, поэтому не буду сбрасывать со счетов его эффективность, но в целом LINQ to SQL оказался чрезвычайно жизнеспособным ORM.

Answer 6

Мой опыт подсказывает мне, что с помощью linq вы можете выполнять задачи быстрее, однако реальные действия с базой данных выполняются медленнее.

Так что ... если у вас есть небольшая база данных, я скажу пойти на это. Если нет, я бы подождал некоторых улучшений, прежде чем менять