Это не мой ИИ. Странно на ИТ-ресурсе читать такие утверждения, что ИИ что-то превращает в помойку. Мое мнение - что в помойку что-угодно превращает негативное отношение к другим людям. Вы же не высказались по существу темы, а просто вбросили оффтоп. В этом плане, с ИИ гораздо интереснее общаться и полезнее. К сожалению. Но к счастью, есть люди, с которыми общение еще возможно по сути.
Коммунистическая экономическая система, в отличие от капиталистической ("рыночной") отличается централизованным подходом к планированию государственных (и/или глобальных) экономических ресурсов. На основании единого национального/наднационального плана счетов. Это очень сложная вычислительная задача и ее решение за счет бюрократических механизмов посыпалось в 20-м веке. Но концептуально - это намного более оптимальная система с точки зрения национальной экономики. А может быть и глобальной. В 21 веке открывается второй шанс с появлением вычислительных мощностей. Математические модели централизованного гос. плана не так уж плохи. Плоха была их реализация, когда для расчетов использовались люди, подверженные человеческому фактору, в частности - коррумпированности.
EF прекрасно справляется с предоставлением доступа к инфраструктуре MSSQL. Поэтому ничто не мешает бизнес-логику в той или иной степени распределять на код БД (если "вера позволяет"). Без linq2db.
В статье не предлагается использовать t-sql в ef. Предлагается смело использовать мощь t-sql (прежде всего CTE, SP, UDF) в MSSQL, а через EF успешно и просто пользоваться этим без громоздкого и низкоэффективного в сложных случаях LINQ и миграций code-first. Как? Об этом статья.
А почему не продолжить простенький CRUD писать, а сложность обработки данных засунуть внутрь кода БД? Как минимум во View. Без Dapper. Прямо в БД MSSQL. Доступ через EF прямой. Об этом статья.
В эпоху цифровой экономики - каждый тик процессора - это деньги. Чем ниже себестоимость, тем выше прибыль. При масштабировании это тоже масштабируется.
"Сырой" код не в проекте, а в MSSQL. Сервер БД может выдавать не только флэт таблицы. Но и View и UDF и SP выполнять. У Postgres аналогичная ситуация. Данная статья - микро туториал по случаю с MSSQL.
EF - отличная ORM. Она вполне допускает использовать весь потенциал разных СУБД, включая очень мощный MSSQL. В этом контексте и статья. Можно и через Dapper.
Просто T-SQL это специализированный язык работы с данными, его возможности существенно шире и глубже, чем C# и соответственно без использования T-SQL для компонентов бизнес-логики весь потенциал MSSQL задействовать невозможно. Если по сути, то разработка сложных процессов по работе с данными может быть гораздо проще.
Скажите, где большая ценность сосредоточена? В кодах или в данных? Вопрос не тривиальный. Данная статья показывает, что на существование имеют право два подхода DDD: Data-Driven-Design и Domain-Driven-Design.
В случае с Data-Driven-Design мысли при разработке начинаются не с внешнего запроса, а с внутреннего. Что значит внутреннего? Это когда архитектор микро-сервиса комплексно и единолично (либо в компактной команде) принимает решение о целесообразности распределения бизнес-логики между компонентами системы. Можно в приложении разместить (более канонично, но менее эффективно и производительно) , можно в ядре БД (более специфический вариант, но иногда оправданный).
Идея в общем-то написать статью появилась после того, как я попросил неглупый ИИ написать LINQ запрос на основании предоставленного ему T-SQL с CTE. LINQ получился довольно громоздким и глючным. ИИ так и сказал, что нет прямого преобразования T-SQL в LINQ. Т.е. LINQ поддерживает лишь базовые возможности T-SQL, но далеко не все. Подходит для простейших случаев отлично. Но если мне нужно быстро сгенерировать отчет с довольно разветвленным запросом к БД, то это конечно намного проще и быстрее сделать на T-SQL. А в случае с выполнением хранимых процедур, все делать через EF - рехнуться можно.
Вообще жизнь на этой планете Вас еще не достала? ) Куда деваться? Суть может быть в разных формах обличена. На синтетичность вы проверили, а в суть не проникли. И не обязаны.
Я учту ваше мнение на будущее. Спасибо, что выразили его. Мне это тоже было интересно.
Кстати, как специалист в этой области, можете просветить по вопросу: что именно мешает проникнуть в суть, если текст написан нейронкой? Нейронка же не сама решила это написать, кто-то воодушевленный вложил в промпт свою свободную волю, которой нет у ИИ. Значит суть какая-то там должна быть?
Как вы относитесь к идее выделения компонентов или автономных модулей бизнес-логики и помещения их внутрь СУБД? Обычно это осуждается большинством современных архитекторов (по моим наблюдениям).
Вот вы попали прямо в точку. Затронули один ключевой вопрос, который тоже сподвигнул меня поднять эту тему. Только я на этот вопрос, для себя ответил диаметрально противоположно.
Я допускаю "размазывание" бизнес логики по Вселенной. И исхожу я здесь не из чувства субъективного вкуса, а из объективного осознания, что бизнес-логика по своей природе является распределенной. И следовательно любые попытки удержать и сконцентрировать ВСЮ бизнес-логику в одном месте - это банальная утопия. Я могу ошибаться, но я к своим 49 годикам пришел пока что к такому опыту и выводу. И я точно уже понял, что во многих темах я довольно бестолков.
Насчет того, что вы согласны с @AlexZyl, и я с ним согласен. ) Но, либо так, либо никак.
Не совсем вас понял. Какое деление странно? Я писал не об делении, а об объединении: EF с T-SQL, чтобы перенести часть наиболее сложной бизнес-логики с LINQ на T-SQL. При этом LINQ остаётся, но приложение разрабатывается и работает быстрее в гибридном подходе.
По поводу T-SQL вы задаёте правильные и интересные вопросы.
Мне кажется, вы как раз смотрите (как и подавляющее большинство современных разработчиков) на вопрос не со стороны СУБД, а со стороны ООП. Поэтому постараюсь осветить тему со стороны конкретной СУБД MS SQL Server.
View. С точки зрения разработки бизнес-логики на движке MSSQL Table и View — это совершенно разные вещи. Внешнее сходство заключается в том, что View возвращает Table. Но, в отличие от Table, View содержит в себе логику, причём сколь угодно сложную. Наверное, это можно назвать инкапсуляцией. И для меня язык SQL (в реализации T-SQL) намного проще и понятнее для сложных запросов к БД, чем LINQ. К тому же LINQ через EF работает на порядок медленнее, а иногда на порядки, чем T-SQL. Ну и можно дальше бесконечно описывать, чем T-SQL не LINQ. LINQ — это узкое место, бутылочное горлышко на пути к движку MSSQL. Поэтому довольно объёмные блоки бизнес-логики иногда имеет смысл делать внутри СУБД. Да и небольшие просто гораздо быстрее и с в несколько раз меньшим объёмом кода удобно делать внутри — всё, что касается работы с реляционными данными.
Хранимые процедуры (SP) и Пользовательские функции (UDF) соответственно так же занимают своё важное место в архитектуре. И хотя вам видится разница небольшой в их вызове через EF, тем не менее интерфейсы у них несколько отличаются. Поэтому приведены раздельные примеры.
Должен заметить: я тут не склоняю никого к такому подходу. Статья опубликована исключительно с целью поделиться своими наблюдениями и опытом. Возможно, кому-то покажется необычным. Кому-то — неудачным.
Из 5 комментариев, ваш вопрос мне больше всех понравился. Что я думаю по вашему вопросу:
1. Вы проницательный и опытный в ИИ человек.
2. Статья сгенерирована Gemini 2.0 Flash Lite. Но суть сгенерирована полностью мною. Статья мною изучена, получена далеко не с первой итерации и одобрена к публикации (моим внутренним критиком) на Хабре.
3. Это моя первая публикация на Хабре. Хотя я тут давно имею аккаунт. Больше читатель. Перед этим ознакомился с правилами и не нашел запрета на генеративные статьи. Если я что-то упустил или не правильно понял, пожалуйста проясните для меня, я как и все, могу ошибаться.
4. Суть статьи полностью задана мною и представляет, как мне кажется, основной халиварный элемент. Форма не столь важна, хотя ИИ точно лучше меня пишет статьи.
5. Возможно вам будет, также, интересно, в результате какого процесса она появилась. Просто я в очередной 100500 раз прорабатывал свой какой-то внутренний незакрытый технический вопрос, ИИ вдруг выдал ответ, который мне показался мне достаточно адекватным и интересным, для того, чтобы его зафиксировать, т.к. весьма вероятно, по сути это может заинтересовать еще кого-то, кроме меня.
6. Мне показалось или нет, что в вашем тезисе содержится некий упрек? Может быть и нет. Если да, то что вы видите в этом негативного?
Спасибо за дополнение. Это уже архитектурная надстройка над тем, о чем в этой статье. Вы абсолютно правы, просто это уже другой аспект не вошедший в тему данной статьи. Можно расширить. Интересно было прочитать про ваш опыт.
Проблему с "зацикливанием" решить можно в двух направлениях: 1. В такие моменты подключать более мощную модель. Как правило, и более дорогую (Claude Sonett 3.7, из того, что я знаю на сегодня). Но оно того стоит в таких ситуациях. 2. Погуглить, найти что нибудь типа ветки на StackOverflow или куска официальной документации по библиотеке и подкинуть в контекст. Часто Claude выручает там, где не справляется Gemini. Но иногда и Клоду приходится подкидывать в контекст "дровишек".
Важно заметить, что объем нового софта будет увеличиваться экспоненциально не только в количественном измерении, а также и в финансовом. Объем рынка/рынков будет увеличиваться в денежном выражении. Это как следствие вышеуказанной зависимости спроса от цены. По мере снижения стоимости разработки нового софта, уже существующие бюджеты заказчиков снижаться не будут (кто выделял бюджет на это направление развития, тот и дальше будет выделять, т.к. это инвестиции в рост. И даже продолжат увеличение). Но также, те, кто ранее не вкладывался в это из-за высокой стоимости, начнет вкладывать небольшие средства, за счет чего будет происходить экономический рост общего объема отрасли.
Это не мой ИИ. Странно на ИТ-ресурсе читать такие утверждения, что ИИ что-то превращает в помойку. Мое мнение - что в помойку что-угодно превращает негативное отношение к другим людям. Вы же не высказались по существу темы, а просто вбросили оффтоп. В этом плане, с ИИ гораздо интереснее общаться и полезнее. К сожалению. Но к счастью, есть люди, с которыми общение еще возможно по сути.
Коммунистическая экономическая система, в отличие от капиталистической ("рыночной") отличается централизованным подходом к планированию государственных (и/или глобальных) экономических ресурсов. На основании единого национального/наднационального плана счетов. Это очень сложная вычислительная задача и ее решение за счет бюрократических механизмов посыпалось в 20-м веке. Но концептуально - это намного более оптимальная система с точки зрения национальной экономики. А может быть и глобальной. В 21 веке открывается второй шанс с появлением вычислительных мощностей. Математические модели централизованного гос. плана не так уж плохи. Плоха была их реализация, когда для расчетов использовались люди, подверженные человеческому фактору, в частности - коррумпированности.
EF прекрасно справляется с предоставлением доступа к инфраструктуре MSSQL. Поэтому ничто не мешает бизнес-логику в той или иной степени распределять на код БД (если "вера позволяет"). Без linq2db.
В статье не предлагается использовать t-sql в ef. Предлагается смело использовать мощь t-sql (прежде всего CTE, SP, UDF) в MSSQL, а через EF успешно и просто пользоваться этим без громоздкого и низкоэффективного в сложных случаях LINQ и миграций code-first. Как? Об этом статья.
Если взять многоэтапный CTE запрос и попытаться его перенести на LINQ - то становится понятна суть идеи статьи.
Спасибо за ваши комментарии и обратную связь.
А почему не продолжить простенький CRUD писать, а сложность обработки данных засунуть внутрь кода БД? Как минимум во View. Без Dapper. Прямо в БД MSSQL. Доступ через EF прямой. Об этом статья.
В эпоху цифровой экономики - каждый тик процессора - это деньги. Чем ниже себестоимость, тем выше прибыль. При масштабировании это тоже масштабируется.
"Сырой" код не в проекте, а в MSSQL. Сервер БД может выдавать не только флэт таблицы. Но и View и UDF и SP выполнять. У Postgres аналогичная ситуация. Данная статья - микро туториал по случаю с MSSQL.
EF - отличная ORM. Она вполне допускает использовать весь потенциал разных СУБД, включая очень мощный MSSQL. В этом контексте и статья. Можно и через Dapper.
Просто T-SQL это специализированный язык работы с данными, его возможности существенно шире и глубже, чем C# и соответственно без использования T-SQL для компонентов бизнес-логики весь потенциал MSSQL задействовать невозможно. Если по сути, то разработка сложных процессов по работе с данными может быть гораздо проще.
Скажите, где большая ценность сосредоточена? В кодах или в данных? Вопрос не тривиальный. Данная статья показывает, что на существование имеют право два подхода DDD: Data-Driven-Design и Domain-Driven-Design.
В случае с Data-Driven-Design мысли при разработке начинаются не с внешнего запроса, а с внутреннего. Что значит внутреннего? Это когда архитектор микро-сервиса комплексно и единолично (либо в компактной команде) принимает решение о целесообразности распределения бизнес-логики между компонентами системы. Можно в приложении разместить (более канонично, но менее эффективно и производительно) , можно в ядре БД (более специфический вариант, но иногда оправданный).
Идея в общем-то написать статью появилась после того, как я попросил неглупый ИИ написать LINQ запрос на основании предоставленного ему T-SQL с CTE. LINQ получился довольно громоздким и глючным. ИИ так и сказал, что нет прямого преобразования T-SQL в LINQ. Т.е. LINQ поддерживает лишь базовые возможности T-SQL, но далеко не все. Подходит для простейших случаев отлично. Но если мне нужно быстро сгенерировать отчет с довольно разветвленным запросом к БД, то это конечно намного проще и быстрее сделать на T-SQL. А в случае с выполнением хранимых процедур, все делать через EF - рехнуться можно.
Вообще жизнь на этой планете Вас еще не достала? ) Куда деваться? Суть может быть в разных формах обличена. На синтетичность вы проверили, а в суть не проникли. И не обязаны.
Я учту ваше мнение на будущее. Спасибо, что выразили его. Мне это тоже было интересно.
Кстати, как специалист в этой области, можете просветить по вопросу: что именно мешает проникнуть в суть, если текст написан нейронкой? Нейронка же не сама решила это написать, кто-то воодушевленный вложил в промпт свою свободную волю, которой нет у ИИ. Значит суть какая-то там должна быть?
Как вы относитесь к идее выделения компонентов или автономных модулей бизнес-логики и помещения их внутрь СУБД? Обычно это осуждается большинством современных архитекторов (по моим наблюдениям).
Вот вы попали прямо в точку. Затронули один ключевой вопрос, который тоже сподвигнул меня поднять эту тему. Только я на этот вопрос, для себя ответил диаметрально противоположно.
Я допускаю "размазывание" бизнес логики по Вселенной. И исхожу я здесь не из чувства субъективного вкуса, а из объективного осознания, что бизнес-логика по своей природе является распределенной. И следовательно любые попытки удержать и сконцентрировать ВСЮ бизнес-логику в одном месте - это банальная утопия. Я могу ошибаться, но я к своим 49 годикам пришел пока что к такому опыту и выводу. И я точно уже понял, что во многих темах я довольно бестолков.
Насчет того, что вы согласны с @AlexZyl, и я с ним согласен. ) Но, либо так, либо никак.
Спасибо за комментарий.
Не совсем вас понял. Какое деление странно? Я писал не об делении, а об объединении: EF с T-SQL, чтобы перенести часть наиболее сложной бизнес-логики с LINQ на T-SQL. При этом LINQ остаётся, но приложение разрабатывается и работает быстрее в гибридном подходе.
По поводу T-SQL вы задаёте правильные и интересные вопросы.
Мне кажется, вы как раз смотрите (как и подавляющее большинство современных разработчиков) на вопрос не со стороны СУБД, а со стороны ООП. Поэтому постараюсь осветить тему со стороны конкретной СУБД MS SQL Server.
View. С точки зрения разработки бизнес-логики на движке MSSQL Table и View — это совершенно разные вещи. Внешнее сходство заключается в том, что View возвращает Table. Но, в отличие от Table, View содержит в себе логику, причём сколь угодно сложную. Наверное, это можно назвать инкапсуляцией. И для меня язык SQL (в реализации T-SQL) намного проще и понятнее для сложных запросов к БД, чем LINQ. К тому же LINQ через EF работает на порядок медленнее, а иногда на порядки, чем T-SQL. Ну и можно дальше бесконечно описывать, чем T-SQL не LINQ. LINQ — это узкое место, бутылочное горлышко на пути к движку MSSQL. Поэтому довольно объёмные блоки бизнес-логики иногда имеет смысл делать внутри СУБД. Да и небольшие просто гораздо быстрее и с в несколько раз меньшим объёмом кода удобно делать внутри — всё, что касается работы с реляционными данными.
Хранимые процедуры (SP) и Пользовательские функции (UDF) соответственно так же занимают своё важное место в архитектуре. И хотя вам видится разница небольшой в их вызове через EF, тем не менее интерфейсы у них несколько отличаются. Поэтому приведены раздельные примеры.
Должен заметить: я тут не склоняю никого к такому подходу. Статья опубликована исключительно с целью поделиться своими наблюдениями и опытом. Возможно, кому-то покажется необычным. Кому-то — неудачным.
Из 5 комментариев, ваш вопрос мне больше всех понравился. Что я думаю по вашему вопросу:
1. Вы проницательный и опытный в ИИ человек.
2. Статья сгенерирована Gemini 2.0 Flash Lite. Но суть сгенерирована полностью мною. Статья мною изучена, получена далеко не с первой итерации и одобрена к публикации (моим внутренним критиком) на Хабре.
3. Это моя первая публикация на Хабре. Хотя я тут давно имею аккаунт. Больше читатель. Перед этим ознакомился с правилами и не нашел запрета на генеративные статьи. Если я что-то упустил или не правильно понял, пожалуйста проясните для меня, я как и все, могу ошибаться.
4. Суть статьи полностью задана мною и представляет, как мне кажется, основной халиварный элемент. Форма не столь важна, хотя ИИ точно лучше меня пишет статьи.
5. Возможно вам будет, также, интересно, в результате какого процесса она появилась. Просто я в очередной 100500 раз прорабатывал свой какой-то внутренний незакрытый технический вопрос, ИИ вдруг выдал ответ, который мне показался мне достаточно адекватным и интересным, для того, чтобы его зафиксировать, т.к. весьма вероятно, по сути это может заинтересовать еще кого-то, кроме меня.
6. Мне показалось или нет, что в вашем тезисе содержится некий упрек? Может быть и нет. Если да, то что вы видите в этом негативного?
Спасибо за вопрос.
Интересное замечание. Тут фокус на работе приложения, а не на работе команды, которая разрабатывает это приложение. Разные аспекты и приоритеты.
Спасибо за дополнение. Это уже архитектурная надстройка над тем, о чем в этой статье. Вы абсолютно правы, просто это уже другой аспект не вошедший в тему данной статьи. Можно расширить. Интересно было прочитать про ваш опыт.
Cursor платный и для оплаты нужна VISA.
Проблему с "зацикливанием" решить можно в двух направлениях:
1. В такие моменты подключать более мощную модель. Как правило, и более дорогую (Claude Sonett 3.7, из того, что я знаю на сегодня). Но оно того стоит в таких ситуациях.
2. Погуглить, найти что нибудь типа ветки на StackOverflow или куска официальной документации по библиотеке и подкинуть в контекст. Часто Claude выручает там, где не справляется Gemini. Но иногда и Клоду приходится подкидывать в контекст "дровишек".
Дополнение к моему предыдущему комментарию.
Важно заметить, что объем нового софта будет увеличиваться экспоненциально не только в количественном измерении, а также и в финансовом. Объем рынка/рынков будет увеличиваться в денежном выражении. Это как следствие вышеуказанной зависимости спроса от цены. По мере снижения стоимости разработки нового софта, уже существующие бюджеты заказчиков снижаться не будут (кто выделял бюджет на это направление развития, тот и дальше будет выделять, т.к. это инвестиции в рост. И даже продолжат увеличение). Но также, те, кто ранее не вкладывался в это из-за высокой стоимости, начнет вкладывать небольшие средства, за счет чего будет происходить экономический рост общего объема отрасли.