Здравствуйте, AlexGin, Вы писали:

IT>>Это провайдер использовался одно время в BLToolkit, но не прижился. Всё современные БД уже имеют вполне зрелые нативные .net провайдеры, поэтому в ODBC необходимость отпадает. К тому же, ODBC нужно дополнительнос ставить, а для большинства провайдеров этого не нужно.
AG>Да, нужно дополнительно ставить, но после этого у пользователя появляетюся возможности управления ODBC — data source (даже в плане оперативного тестирования канала связи с источником данных); кроме того — ODBC обладает универсальностью.

И что это даёт? Кроме того, что пользователь получает какую-то возможность, о которой он может и понятия не имеет.

AG>То есть — возможности применения этого самого data source НЕ ТОЛЬКО в приложениях на .NET, но и приложениях на C++ например.

Очень хорошо. Никто не мешает поставить это отдельно для C++. Лишать себя удобств работы с нативными провайдерами ради такой "мегафичи" я бы точно не стал. Например, поддерживает ли ODBC драйвер весь диалект конкретной БД? Есть ли там поддержка BulkCopy? И т.п.

AG>ИМХО, строковый натуральный SQL-запрос я могу отладить в MS SQL Server Management Studio, в отличие от LINQ.

У меня в Output Window каждый чих, генерируемый LINQ. Можно просто смотреть на SQL, можно скопировать Management Studio и отладить по вкусу. Едиснтвенная проблема — BulkCopy. Но она такая же проблема и без LINQ. Но linq2db поддерживает режим BulkCopy как Multiple Row Insert, т.е. можно временно переключиться и получить в Output Window полный лог работы приложения с БД. Дальше хоть обкопируйся, хоть оботлаживайся.

AG>Там же (в MS SQL Server Management Studio) — можно поиграть с запросом, видоизменить его или оптимизировать.

Это я в курсе.

AG>Риторический вопрос — что мне даст LINQ

В этой теме уже несколько раз вполне конкретно отвечали на этот вопрос. В частности, linq2db — это типизированный SQL интергированный в C#. В результате мы имеем строгую типизация вместо манипулиции текстовыми константами, навигацию по коду, все доступные рефакторинги, отладчик.

IT>>LINQ в принципе нельзя сравнивать с вещами типа ODBC. LINQ может работать поверх ODBC, ADO.NET, XML или просто объектов.
AG>В смысле — работа с XML, как с объектами БД? Я верно понял?

Верно.

AG>Тем не менее, вполне пишу текстовые SQL-запросы в кодах (будто C#, или C++). Отлаживаю — в студии серверя. ЧЯДНТ?

Тебе знаком термин "Рефакторинг базы данных"? Большинство девелоперов, когда до них доходит что это такое падют в обморок или крутят пальцем у виска. Это одна из самых трудоёмких задач с непредсказуемым результатом. Если у тебя в коде нет ни строчки на SQL, а только LINQ, то задача рефакторинга БД лишь чуть сложнее рефакторинга обычного C# кода.

AG>Ключевой вопрос — как все это отлаживать???

Почему ты думаешь, что если мы используем LINQ, то мы не знаем или вообще не видим SQL. SQL у меня постоянно перед глазами. Разница лишь в том, что я не пишу его руками. Руками я пишу LINQ запросы, а SQL генерируется. Причём в human friendly виде, то хорошо отформатированный, со всеми входными параметрами, готовый к копированию в Management Studio и подробному анализу и отладке. Вот здесь на видео можно посмотреть как это происходит вживую.