Учиться LinqToSql или придерживаться ADO.NET?

Question

Я обсуждаю, какую технологию использовать для будущего проекта ASP.NET.

Предположения:

• Я буду использовать Visual Studio 2008 SP1 (.NET Framework 3.5)
• Серверной частью будет база данных SQL Server 2005 (или, возможно, 2008)
• Код будет написан на C #
• У меня уже есть опыт работы с LinqToObjects и LinqToXml
• У меня также есть опыт работы с ADO.NET, и некоторые библиотеки уже созданы
• Проект относительно небольшой
• На сайте будет представлено около пяти экранов
• В базе данных может быть шесть или семь таблиц
• Возможно будет 25-50 активных пользователей
• Транзакций в день, вероятно, будет около 5-10 вершин
• Минимальные персональные данные будут храниться
• Последствия сбоя или взлома сайта будут минимальными

Параметры:

1. Напишите хранимые процедуры и вызывайте их с помощью ADO.NET. Я все еще могу использовать LinqToObjects, как только я закончу заполнять мой DataSet.

2. Используйте то, что я знаю о Linq, уже для изучения LinqToSql.

Анализ:

Я уже знаю, как сделать вариант 1, но я действительно хотел бы использовать исключительно Linq. Проблема с вариантом 2 заключается в том, что, согласно всему, что я прочитал, LinqToSql, вероятно, будет признан устаревшим в пользу Entity Framework.

Вопросы:

1. Насколько крута кривая обучения для LinqToSql, если вы уже знакомы с другими технологиями Linq?

2. Стоит ли тратить любое время на изучение LinqToSql, учитывая, что Microsoft может его не развивать?

3. Поможет ли понимание LinqToSql мне однажды понять Entity Framework или они слишком разные?

4. В конечном итоге, какой вариант вы бы порекомендовали для моей ситуации?

Обновление:

Я не хочу, чтобы это потерялось в комментариях: marc_s указал, что LinqToSql находится в стадии дальнейшего развития, по крайней мере, начиная с .NET 4.0. Ссылка: http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40.

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

Одна вещь, о которой я не спрашивал в своем первоначальном посте, но должна иметь в виду: могут ли недостатки в Entity Framework повлиять на этот проект?

Спасибо за ответы.

Дальнейший анализ

Вот список недостатков LinqToSql, основанный на некоторых комментариях ниже:

1. Вы должны постоянно обновлять таблицы и элементы в конструкторе по мере внесения изменений в базовую базу данных. Нет способа «обновить» или «синхронизировать» его, чтобы он автоматически распознавал изменения.
2. Управление версиями осложняется тем, что конструктор не создает базовые файлы в согласованном порядке.
3. Конструктор LinqToSql генерирует код, отличный от SqlMetal.
4. Есть проблемы / ошибки, связанные с энергичной загрузкой.

Из них пункт 1 вызывает наибольшее беспокойство у меня. Даже при небольшом проекте изменения неизбежны. Помню, однажды, когда я пытался использовать дизайнер Windows Forms для сопоставления с базой данных, и это много раз взрывалось у меня на лице, я отказался от него в пользу использования собственных вспомогательных классов ADO.NET.

Тем не менее, похоже, что SqlMetal может отлично справиться с моими потребностями. Я запускаю команду, она восстанавливает все с нуля из базы данных, все готово. Если я сохраню свою базу данных простой (только таблицы - без хранимых процедур, представлений или функций), возможно, SqlMetal - это все, что мне нужно.

Answer 1

LINQ to Sql довольно прост, если вы уже знаете LINQ to Xml или объекты («объекты» Linq - это просто «списки») ...

Linq To Sql не осуждается Microsoft, они просто предлагают перейти на EF. Он не будет обновлен.

Linq To Sql можно было увидеть почти как на EF. С EF вы можете делать более сложные вещи, но на базовом уровне это почти то же самое (для вашего сайта с 7 таблицами это не имеет никакого значения).

Для вашей ситуации я предлагаю перейти с LINQ. Это весело и быстрее, чем SP + ADO.NET. Использование ORM в наше время является почти хорошим выбором. Не использовать это должно быть исключением (для меня).

Answer 2

Я согласен с Давиде Вости, но вы можете рассмотреть другие варианты, например NHibernate (которые также поддерживают LINQ).

Текущее воплощение EF не впечатляет - оно создает действительно противный T-SQL, выполнение которого занимает много времени.

В настоящее время мы используем EF, но я в последний раз выбираю EF для .NET 3.5. Я даю ему еще один шанс в .NET 4, но если он не улучшится значительно, я выберу другие варианты (и LINQ to SQL вряд ли будет одним из них).

Answer 3

1. Насколько крута кривая обучения для LinqToSql, если вы уже знакомы с другими технологиями Linq?

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

2. Стоит ли тратить время на изучение LinqToSql, учитывая, что оно может не будет дальше разрабатываться Microsoft?

Я бы сказал, что это не сложно подобрать, если вы уже используете технику Linq. Кроме того, Microsoft продолжит поддерживать и развивать Linq2Sql, как отметил marc_s. Скотт Хансельман использует Linq2Sql для своего проекта Nerd Dinner (http://nerddinner.codeplex.com/)

3.Понимание LinqToSql поможет мне однажды понять Entity Framework или они> слишком разные?

Я использовал много Linq2Sql и только очень маленький кусочек Entity Framework, они похожи, но различны. Основы во многом совпадают, и я не участвовал ни в каких сверхсложных случаях использования.

4.В конце концов, какой вариант вы бы порекомендовали для моей ситуации?

Если бы я разрабатывал сайт, как вы предложили, я бы серьезно посмотрел на Linq2Sql, вы, вероятно, могли бы заставить основы работать через несколько часов и принять решение, если кривая обучения больше, чем вы хотите иметь дело. (ИМХО, я сомневаюсь, что так и будет.)

Answer 4

Взгляните на Subsonic , он находится в прекрасной середине простоты использования Linq для SQL и NHibernate.

с subsonic вы получаете некоторые из приятных функций NHibernate, таких как разработка на основе модели, автоматическое создание схемы базы данных и поддержка баз данных, отличных от Sql Server.

Существует также хорошая страница сравнения , в которой перечислены различия между тремя ORMS

Answer 5

1 - Насколько крута кривая обучения для Linq-Sql, если вы уже знакомы с другими технологиями Linq?

Я бы сказал, что вы рассмотрели, возможно, 50% кривой обучения, но это может быть более или менее, я просто догадываюсь. LinqToSql - это намного больше, чем просто Linq.

2 - Стоит ли тратить время на изучение Linq-To-Sql, учитывая, что оно может не будет дальше разрабатываться Microsoft?

Есть преимущества в изучении любого ORM. Если бы я собирался изучать ORM, LinqToSql, вероятно, был бы №3 или №4 в моем списке. Общение Microsoft о будущем LinqToSql в лучшем случае было облачным, и они, очевидно, прилагают немало усилий для продвижения EntityFramework в будущем. Microsoft всегда может изменить свое мнение, и вы должны прийти к своим собственным выводам.

3 - Поможет ли понимание Linq-To-Sql мне однажды понять Entity Framework или они слишком разные?

Все ORM имеют схожие функции, и изучение любого ORM поможет вам понять другие ORM. LinqToSql на самом деле имеет ряд тех же функций и недостатков, что и EntityFramework, поэтому есть больше сходства, чем вы могли ожидать. Тем не менее, я бы рекомендовал изучить EntityFramework до LinqToSql.

4 - В конечном итоге, какой вариант вы бы порекомендовали для моей ситуации?

Лучшим ORM для .NET 3.5 в подавляющем большинстве ситуаций является NHibernate. NHibernate поддерживает Linq, но поддерживает его иначе, чем Microsoft ORM. Тем не менее, вы не указали причину, которая явно сделала бы NHibernate лучше ADO.NET для вашей ситуации. Я бы не рекомендовал ни LinqToSql, ни EntityFramework для вашей ситуации.