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

Question

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

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

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

Answer 1

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

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

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

Ресурсы:

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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