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

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

S>>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?

IT>Если есть возможность использовать .NET, то только LINQ и никаких древних какашек мамонта типа ODBC.
В разработках под .NET также можно использовать: System.Data.Odbc ( https://msdn.microsoft.com/en-us/library/system.data.odbc(v=vs.110).aspx ).
Так — в чём же проблема? В религии?
Может просто вериться, что раз LINQ появился позже, то он лучше

Здравствуйте, Олег К., Вы писали:

ОК>Да? А вот это что такое?

А вот что это такое?

ОК>У тебя не только Си Шарповский код дублирует структуру базы, но и полагается на внутренности самой базы!

Ну дублирует и что? Если ты думаешь, что это как-то сильно напрягает, то ты ошибаешься. Структура классов генерируется по базе одним нажатием кнопки. Мы даже наследование от интерфейсов автоматизировали. Если видим, что в таблице есть поля, например, EffectiveDate и ExpirationDate, то тут же дабвляем классу наследование от какого-нибудь IEffectible. Используем комментарии к полям и таблицам в базе. Если видим там наличие текста [Obsolete], то добавляем такой атрибут к классу/свойству. В общем, напрягов абсолютно никаких. У нас в солюшине есть ещё чисто датабазный проект, который dbmdl. Вот с ним проблем куда больше. А это всё фигня.

По поводу полагается на внутренности самой базы ничего не понял.

ОК>З.Ы. На вопросы ты так и не ответил! Потому что не можешь ответить!

Ты вопрос сформулируй сначала внятно. А то ты уже несколько раз меня упрекнул в том, что я на что-то там не ответил, но при этом забыл сказать на что именно.

Здравствуйте, Олег К., Вы писали:

IT>>Вот! Послушайте умного человека!
ОК>Да ты ведь даже не понял его ответа!

Я с тебя ржу.

ОК>Хрен горы согласился с тем, что linq2db нарушает инкапсуляцию базы, но тем не менее, по его мнению, если технология удобна, то почему бы не плюнуть на философию и тупо не использовать ее в проекте? Я, в принципе, согласен с таким утверждением, но лично мне, как purist-у, не просто такое (ORM фреймворки) принять.

Я тебе тут уже целый пост про твою философию написал, но ты так ничего и не понял, пурист ты наш. Объясняю ещё раз. На философию мне положить большой болт. Это самое последнее о чём нужно думать. Есть более важные вещи, такие как поддержка кода и организация рабочего процесса. Тряпочка для протирки монитора важнее, чем вся твоя философия. И заканчивай уже на это напирать. На меня это действует с совершенно обратным знаком.

ЗЫ. Извини, но на патерны и прочий булшин у меня тоже передозировка. На одном из моих проектво был один дебил, который ходил с табличкой design pattern police. Своей философией и паттернами задолбал абсолютно всех. Там где он не мог применить никакого паттерна, он применял визитор паттерн. В конце концов, чувак этот в результате за неуспеваемость был разжалован из архитекторов в девелоперы. С тех пор у меня устойчивая аллергия на подобных филосовствующих придурков.

Здравствуйте, Олег К., Вы писали:

ОК>Удобство не отменяет филосовских проблем с технологией! О чем я тебе уже который пост говорю.

Всё, с философией завязываем.

Здравствуйте, Олег К., Вы писали:

ОК>Ну а неправильные запросы как ты отлаживаешь? Свои и чужие. Речь сейчас о Си шарпе, если что.

Что значит неправильные?

Здравствуйте, Олег К., Вы писали:

ОК> Вот простейший пример: запрос пишется на другом языке — Си Шарп или Джава — и чтобы его проверить, нужно скомпилировать код и проранать его. Для сравнения, запросы на сиквеле можно сразу же проранать в менеджмент студии. Меньше телодвижений. Точно также и отладка. Надо получить созданный сиквел и проранать его в студии если что-то непонятно. Не забываем, что нижележащий инструмент все-таки разговаривает на сиквеле.

Я ждал именно этого сообщения. Апологетам SQL только на это и остаётся напирать. Потому что это единственное удобство, якобы предоставляемое чистым сиквелом: написал запрос, тут же можно исполнить.
Однако, открой для себя хотя бы LinqPad: в нём можно сразу же писать linq-запросы к БД. Ни единой строчки маппинга таблиц БД на сущности C# писать не нужно! Они генерируются автоматически, моментально.

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

AG>В разработках под .NET также можно использовать: System.Data.Odbc ( https://msdn.microsoft.com/en-us/library/system.data.odbc(v=vs.110).aspx ).

Это провайдер использовался одно время в BLToolkit, но не прижился. Всё современные БД уже имеют вполне зрелые нативные .net провайдеры, поэтому в ODBC необходимость отпадает. К тому же, ODBC нужно дополнительнос ставить, а для большинства провайдеров этого не нужно.

AG>Так — в чём же проблема? В религии?

Ну вот, опять началось У меня сразу вопрос, у тебя есть хотя бы общее представление о LINQ?

AG>Может просто вериться, что раз LINQ появился позже, то он лучше

Понятно. На предыдущий вопрос можно не отвечать.

LINQ в принципе нельзя сравнивать с вещами типа ODBC. LINQ может работать поверх ODBC, ADO.NET, XML или просто объектов. linq2db, linq2sql, EF и прочие — это LINQ провайдеры для баз данных. Каждый со своими достоинствами и недостатками. Например, философия (где там Олег К.?) linq2db — это типизированный SQL интегрированный в C#. Филисофия EF (от которой постепенно отходят) — это жирный ORM, всемогутор, симулятор персистентности объектной модели приложения и поставщик прочих entity services. linq2sql — удачная проверка концепции, загубленная теми, кому эта технология в дальнейшем была отдана для поддержки и продвижения.

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

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

IT>Ну вот, опять началось У меня сразу вопрос, у тебя есть хотя бы общее представление о LINQ?
Некоторое представление есть. В кода проекта моего приложения на C# — пишу SQL-подобное.
Хотя, в том же приложении, я могу написать строковый SQL-запрос (как обычно и делаю).
ИМХО, строковый натуральный SQL-запрос я могу отладить в MS SQL Server Management Studio, в отличие от LINQ.
Там же (в MS SQL Server Management Studio) — можно поиграть с запросом, видоизменить его или оптимизировать.
Риторический вопрос — что мне даст LINQ

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

IT>linq2db, linq2sql, EF и прочие — это LINQ провайдеры для баз данных. Каждый со своими достоинствами и недостатками. Например, философия (где там Олег К.?)
Я не придерживаюсь той точки зрения, что хранимые процедуры полезны. Лично я не пользуюсь хранимками — уже почти 10 лет.
Тем не менее, вполне пишу текстовые SQL-запросы в кодах (будто C#, или C++). Отлаживаю — в студии серверя. ЧЯДНТ?

IT>linq2db — это типизированный SQL интегрированный в C#. Филисофия EF (от которой постепенно отходят) — это жирный ORM, всемогутор, симулятор персистентности объектной модели приложения и поставщик прочих entity services. linq2sql — удачная проверка концепции, загубленная теми, кому эта технология в дальнейшем была отдана для поддержки и продвижения.
ИМХО всё это объединяет исполнимый код с кодом SQL-запроса. Не буду уповать на философию.
Ключевой вопрос — как все это отлаживать???

Здравствуйте, 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 и подробному анализу и отладке. Вот здесь на видео можно посмотреть как это происходит вживую.

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

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

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

IT>Вот здесь на http://blog.linq2db.com/2015/05/linq-crud-operations.html можно посмотреть как это происходит вживую.
Спасибо, великолепный материал! Посмотрю и поизучаю.
Попутный вопрос: у меня из MS Visual Studio есть: MSVS-2008 (team system) и MSVS-2013 (community edition) — что из них для этого подходит?

P.S. В этом видео имеется что-то новое, по крайней мере для меня!
Возможно, пригодится в будущем!

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

AG>Термин слыхал, однако практически с этим не сталкивался. В основном рефакторинг — кодов приложения.

Это потому-что легче написать систему с нуля, чем рефакторить её начиная с БД.

AG>Попутный вопрос: у меня из MS Visual Studio есть: MSVS-2008 (team system) и MSVS-2013 (community edition) — что из них для этого подходит?

2013 точно подойдёт. 2008 если не ошибаюсь поддерживает только .NET FW 3.5, а нужно минимум 4.0.

IT> для меня теперь словосочетание рефакторинг базы данных стало вполне привычным.
Стало? А раньше были проблемы? На ваших проектах автотесты покрывали не всю работу с базой?

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

IT>> для меня теперь словосочетание рефакторинг базы данных стало вполне привычным.
AP>Стало? А раньше были проблемы? На ваших проектах автотесты покрывали не всю работу с базой?

1. Когда ты приходишь на проект, где нужно рефакторить БД, то об автотестах там как правило никогда не слышали.
2. Автотесты — это для идеальных проектов, где из время, стоимость, качество можно без труда выбрать все три состаяляющих. Ну, или если это совсем крошечный проект.

IT> Я с тебя ржу.

Продолжай. Смех без причины — признак, сам знаешь, кого.

ОК>>Хрен горы согласился с тем, что linq2db нарушает инкапсуляцию базы, но тем не менее, по его мнению, если технология удобна, то почему бы не плюнуть на философию и тупо не использовать ее в проекте? Я, в принципе, согласен с таким утверждением, но лично мне, как purist-у, не просто такое (ORM фреймворки) принять.

IT>Я тебе тут уже целый пост про твою философию написал, но ты так ничего и не понял, пурист ты наш. Объясняю ещё раз. На философию мне положить большой болт. Это самое последнее о чём нужно думать. Есть более важные вещи, такие как поддержка кода и организация рабочего процесса. Тряпочка для протирки монитора важнее, чем вся твоя философия. И заканчивай уже на это напирать. На меня это действует с совершенно обратным знаком.

Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.

IT>ЗЫ. Извини, но на патерны и прочий булшин у меня тоже передозировка. На одном из моих проектво был один дебил, который ходил с табличкой design pattern police. Своей философией и паттернами задолбал абсолютно всех. Там где он не мог применить никакого паттерна, он применял визитор паттерн. В конце концов, чувак этот в результате за неуспеваемость был разжалован из архитекторов в девелоперы. С тех пор у меня устойчивая аллергия на подобных филосовствующих придурков.

Ты опять присваиваешь мне свои фантазии!

ОК>>Удобство не отменяет филосовских проблем с технологией! О чем я тебе уже который пост говорю.

IT>Всё, с философией завязываем.

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

Заодно еще откажись от инкапсуляции в Си шарповом коде. Сделай все переменные члены публичными и откажись от функций членов!

ОК>>Да? А вот это что такое?

IT>А вот что это такое?

Ты о чем, чувак? И почему вырезал вопрос где я тебя попросил показать где я, якобы, сказал, что "ты будешь писать на сиквеле?"

ОК>>У тебя не только Си Шарповский код дублирует структуру базы, но и полагается на внутренности самой базы!

IT>Ну дублирует и что? Если ты думаешь, что это как-то сильно напрягает, то ты ошибаешься. Структура классов генерируется по базе одним нажатием кнопки. Мы даже наследование от интерфейсов автоматизировали. Если видим, что в таблице есть поля, например, EffectiveDate и ExpirationDate, то тут же дабвляем классу наследование от какого-нибудь IEffectible. Используем комментарии к полям и таблицам в базе. Если видим там наличие текста [Obsolete], то добавляем такой атрибут к классу/свойству. В общем, напрягов абсолютно никаких. У нас в солюшине есть ещё чисто датабазный проект, который dbmdl. Вот с ним проблем куда больше. А это всё фигня.

Неважно вручную структура описана или автоматически сгенерирована. Лучше, конечно же, второе но не в этом суть. Главное что она есть и что запросы в Си шарповом коде знают о внутренностях базы. Но для тебя, ведь, есть только две философии. Та которая твоя и та которая неправильная.

IT>По поводу полагается на внутренности самой базы ничего не понял.

Все поняли а ты так ничего и не понял?

ОК>>З.Ы. На вопросы ты так и не ответил! Потому что не можешь ответить!

IT>Ты вопрос сформулируй сначала внятно. А то ты уже несколько раз меня упрекнул в том, что я на что-то там не ответил, но при этом забыл сказать на что именно.

Сформулировал внятно. Даже пронумеровал их. Это ты предпочел пропустить неудобные тебе вопросы мимо ушей.

ОК>>Ну а неправильные запросы как ты отлаживаешь? Свои и чужие. Речь сейчас о Си шарпе, если что.

IT>Что значит неправильные?

То и значит. Продолжай делать вид что не понимаешь.

K>Я ждал именно этого сообщения. Апологетам SQL только на это и остаётся напирать. Потому что это единственное удобство, якобы предоставляемое чистым сиквелом: написал запрос, тут же можно исполнить.
K>Однако, открой для себя хотя бы LinqPad: в нём можно сразу же писать linq-запросы к БД. Ни единой строчки маппинга таблиц БД на сущности C# писать не нужно! Они генерируются автоматически, моментально.

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

Здравствуйте, Олег К., Вы писали:
IT>>На философию мне положить большой болт. Это самое последнее о чём нужно думать. Есть более важные вещи, такие как поддержка кода и организация рабочего процесса
ОК>Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.
Подозреваю, если для решения некоторой конкретной задачи программирование в процедурном стиле (в стиле Си, как ты пишешь) без инкапсуляции, приватных методов и свойств позволит создать более компактный, выразительный, легко читаемый, тестируемый и поддерживаемый код, то Игорь без колебаний махнет рукой на все фенечки ООП. Для HelloWord или вычисления корней квадратного уравнения ты же станешь приватные методы писать правда (я утрирую конечно)?
Другой вопрос — даст ли переход на Си-стиль какой-нибудь профит?
А вот от отказа от DAL Игорь, очевидно, профит получает.

Вообще, всякие паттерны, ООП, вирутальности, инкапсуляции, слоистую структуру, ORM-ы, сервисы и пр, и пр, и пр. придумали для того, чтобы сделать код проще для написания, понимания и рефакторинга. Иными словами все выше перечисленное — не есть самоцель, а лишь инструменты. Цель — достижение простоты и выразительности. Вернее снижение сложности в одном аспекте за счет неизбежного повышения сложности с другом аспекте (у Игоря на этот счет есть замечательная, кстати, вполне философская статья

Автор(ы): Игорь Ткачёв
Дата: 06.12.2002

).
Если инструмент подходит для достижения цели, его используют, если не подходит — его не используют.

Когда-то, тот же IT, если не ошибаюсь, писал (ссылку уже не найду), что иметь слой DAL в программе — это так же считается хорошим тоном как чистить зубы по утрам и вечерам. Но если зубов нет, то и чистить, в общем-то, ничего не надо. Иными словами, задача слоя DAL в одном месте локализовать функционал преобразования нетепизированных объектов БД в строго типизированные объекты языка программирования (C# например) и наоборот. Если проблемы с этим преобразованием нет (а LINQ эту проблему снимает), то проблема, которую призван решить DAL, исчезает. Соответственно, становится не нужным и сам DAL.

Твой же пуристический подход предполагает следование догмам независимо от того нужны ли они и продуктивны ли.

Здравствуйте, Олег К., Вы писали:

ОК>Очередной костыль. Родной язык базы — сиквел. Вместо этого писать те же самые запросы на Си шарпе лишь с одной целью — чтобы иметь возможность перенести их в Си шарповский код. Запросы те же, синтаксис только другой. Тебе не кажется это уродливым?

База — это хранилище данных. То есть место на диске или в оперативной памяти. Таким образом, родной язык для базы — это команды перемещения головки жёсткого диска, чтение секторов и т. п. Если вместо hdd оказывается ssd, внезапно, меняется язык для доступа к данным. Если база расположена in memory — то доступ к данным идёт на "языке" адресов ram. Хотел философию? Получай!

Современный разработчик оперирует объектами-сущностями. Эти объекты можно объединять в различные коллекции. Эти одиночные объекты и коллекции можно одной командой привязать к гую, послать по сети, сохранить/прочитать в/из файл(а). По твоей философии каждый раз нужно использовать собственный язык, "родной" для данного типа носителя, сети, графической библиотеки и т. п. Никто сейчас так не делает! Такова современная философия!

Если имеется у меня тип Person, то я хочу просто работать к коллекцией Persons, не важно, откуда она берётся и куда сохраняется. Если данные хранятся в xml-файле, то я прочитаю их двумя строками кода с помощью xml-сериализатора. Ты, вероятно, будешь считать этот файл побайтово, преобразоывать байты в нужную кодировку, парсить xml вручную, находить нужные элементы и атрибуты, записывать их в свойства класса. Мрак... Конечно, ты сразу вычленишь этот код чтения-парсинга в отдельные удобные классы/методы, назовёшь его DAL. Далее, прикладной программист будет использовать этот DAL (аналогично хранимкам в СУБД). То есть взаимодействия с "родным" языком хранилища у прикладника не будет!

В философии IT и меня точно также нет взаимодействия с сырыми байтами, прочитанными из файла и сырым sql СУБД. Вместо них используется ранее написанный кем-то DAL. Например, linq2db.
Я думаю ты согласишься, что не обязательно каждому разработчику напрямую взаимодействовать с БД? Кто-то пишет слой доступа, а кто-то им пользуется. Так вот linq2sql, EF, linq2db — это и есть заранее написанные кем-то функции работы с БД.
Очевидно, у тебя синдром NIH. Если ты сам написал хранимки — это хорошо. Если код доступа к БД сгенерирован кодом, написанным кем-то другим — это почему-то плохо.