Связи - главная сила SQL. Данные из разных таблиц могут быть связаны. Например, таблица Пользователи и таблица Заказы связаны через user_id. Это позволяет одним запросом найти все заказы конкретного пользователя, соединив таблицы. Отсюда и название — «реляционные» (от англ. relation — связь).
Я, конечно знаю, что "программисту образование не нужно". Но если вы уж не хотите читать и не читаете учебники, то, перед тем как писать, прочитали бы хотя бы википедию, про то, что в случае РБД означает термин "relation" ("отношение").
Я ожидал, что статья будет про PowerShell и Windows Terminal. А тут про какую-то пое*ень, которая яркость экрана с помощью мыши из трея может менять... :(
Автор уже меня обосрал за "непонимание истинных принципов outbox", хотя практических, (с примерами кода), ответов на ваш вопрос, как и у всех свидетелей микросервисов у него не найдется. Статья, по сути, от очередного Почетного Участника Всех Конференций Архитекторов всех Архитектур :))
Как вариант - среди разработчиков старшего возраста больше тех кто понял, что на качество всем уже давно начхать и главный полезный навык в работе это сделать всё на отъе*ись и успешно впарить это дальше по цепочке. А если так, то почему бы и не повайбить. Сначала копируешь код из ИИ в PR, потом просто копируешь комментарии из PR в ИИ и по кругу - красота, чо - ведь рано или поздно ревьюер зае*ется и PR одобрит, цель достигнута :)
Если бы это было так. На самом деле всё полностью наоборот потому что: "Да х*ли тут делать, ведь всё же уже написано и почти работает - кучу денег вложили". И попробуй объяснить, что с этим "почти работает" надо полмесяца провозиться только чтобы оно хотя бы раз из трёх просто запускалось. А еще обычно это закончится тем что возьмут каких-то других говноделов, которые будут без конца лепить горбатого: "вот-вот и всё будет", а потом их точно так же как предыдущих нах пнут, когда уже дальше кормить обещаниями станет совсем уж невозможно, и этот шабаш будет продолжаться по кругу пока "ишак не сдохнет". Весь аутсорс, например, вообще так по жизни работает - в этом его суть.
а я вот с кодом таких "синьоров" разбираюсь потом и переписываю, чтобы он хотя бы работать начал
Вы даже если к двум монетам задачу сведете, которые окажутся разного веса, то всё равно еще будет неизвестно какая именно из них фальшивая. Может я сейчас туплю просто.
Проект делался еще когда был unityContainer, Scoped тогда не было.
Ну, хорошо, (даже если оставить в стороне ценность вашей задумки в целом), но зачем тут вообще Unity сейчас - вы можете объяснить? "То что мертво умереть не может" (с)? Его почти никто не использовал даже когда он был живой, а сейчас у него даже последнему коммиту в его репозиторий, по-моему, уже больше пяти лет :)
Всё правильно, но, по пункту №2 - "netstandard" уже давно "deprecated" и его следует использовать только если нужна совместимость с совсем уж старыми (до .NET 5) framework-ами. А так, следует либо указывать самый старый поддерживаемый (например net6.0), либо, если имеет смысл, то перечислять несколько, например, если хочется или нужно для разных TFM написать разный код или задать разные свойства MSBuild в *.csproj файле.
Можно (и, как правило, нужно) в дополнение к "saga" и "compensating" использовать еще "transactional outbox". Но, опять-таки, это тоже дополнительное усложнение - вам уже придется не просто брать и отправлять сообщение второму сервису, а встраивать в первый еще какой-то планировщик, который будет по таймеру проверять этот "outbox" на наличие записей и отправлять во второй сервис сообщение до тех пор пока тот явно ответным сообщением не подтвердит, что он его обработал. А тут уже возникают еще новые вопросы, например, как подбирать интервал этого таймера чтобы и задержка в синхронизации данных сервисов была приемлемой, но при этом не перегружать брокер потоком одинаковых сообщений, или, например, следует ли установить какой-то лимит на количество повторных попыток, или нет. И т.д. и т.п.
Как вариант (что, по личному опыту, на самом деле, обычно и делают :) это вообще по сути забить на всё это, списав на то, что подобные ситуации (какой-то сервис, или брокер, или какая-нибудь из БД, или всё вместе, просто взяло и тупо внезапно упало в самый неподходящий момент) они всё-таки нетипичны и, в случае чего, админы вместе с поддержкой руками будут разруливать проблемы типа "продали клиенту несуществующий товар" или "деньги за заказ взяли, а заказ на сборку так и не поступил" и прочие, в случае возникновения таковых.
Понимаете, в чем дело. Вы, как пример, приводите простой код, который корректен только для идеального случая, когда всё идёт как задумано, а когда, вот, начинаются вопросы, "а что, если вот это, или вот то пошло не так", то даёте только общие ответы, которые выглядят просто. Но, если все эти ответы: "во первых, во вторых", и т.п., начать воплощать в вашем простом коде, то в результате на один только код потребуется штуки три таких статьи, и любой, кто на этот код посмотрит, вполне резонно скажет: "- Да ну их на... эти ваши микросервисы".
Я сам с микросервисами работаю уже больше семи лет, и мне вся идея сначала очень понравилась, но навозившись с ними за всё это время я полностью поменял к ним отношение. Право на существование они имеют, да. Если у вас проект, команда, и/или нагрузки масштабов какого-нибудь Netflix. В остальных случаях ну его в пень - выгода от них даже если есть, то и на доли процента не покрывает всего дрочева, связанного с их реализацией (при условии если реализация не полное го*но - но это уже отдельная тема).
И еще вы заблуждаетесь насчет "eventual consistency" и "saga". Потому что "saga" это как раз только "eventual" consistency и есть. Если вам нужна "полная" consistency, то вам нужна не saga, а "2PC" (two-phase commit) с распределенными блокировками, а это настолько сложно в реализации (опять-таки если делать всё правильно), что я даже никогда и не слышал, чтобы кто-то в реальности с этим связывался.
В дополнение к тому что выше -
Span<T>позволяет работать со staсkalloc-массивами без использования unsafe кода.Я, конечно знаю, что "программисту образование не нужно". Но если вы уж не хотите читать и не читаете учебники, то, перед тем как писать, прочитали бы хотя бы википедию, про то, что в случае РБД означает термин "relation" ("отношение").
Я ожидал, что статья будет про PowerShell и Windows Terminal. А тут про какую-то пое*ень, которая яркость экрана с помощью мыши из трея может менять... :(
Автоотказ от бота через 5-10 мин. после отклика - буду теперь знать, что в нынешнее время это называется "долгий отбор" :))
Автор детально написал об этом, а если кратко резюмировать его мысль - меньше работать и больше пи*деть языком где только можно.
Да. Сейчас все больше и больше ИТ-шников уходят в электрики, сантехники, и плотники после многомесячных безрезультатных поисков работы.
Я результаты этого "величайшего" искусства на работе разгребаю каждый день :((
Автор уже меня обосрал за "непонимание истинных принципов outbox", хотя практических, (с примерами кода), ответов на ваш вопрос, как и у всех свидетелей микросервисов у него не найдется. Статья, по сути, от очередного Почетного Участника Всех Конференций Архитекторов всех Архитектур :))
Как вариант - среди разработчиков старшего возраста больше тех кто понял, что на качество всем уже давно начхать и главный полезный навык в работе это сделать всё на отъе*ись и успешно впарить это дальше по цепочке. А если так, то почему бы и не повайбить. Сначала копируешь код из ИИ в PR, потом просто копируешь комментарии из PR в ИИ и по кругу - красота, чо - ведь рано или поздно ревьюер зае*ется и PR одобрит, цель достигнута :)
Если бы это было так. На самом деле всё полностью наоборот потому что: "Да х*ли тут делать, ведь всё же уже написано и почти работает - кучу денег вложили". И попробуй объяснить, что с этим "почти работает" надо полмесяца провозиться только чтобы оно хотя бы раз из трёх просто запускалось. А еще обычно это закончится тем что возьмут каких-то других говноделов, которые будут без конца лепить горбатого: "вот-вот и всё будет", а потом их точно так же как предыдущих нах пнут, когда уже дальше кормить обещаниями станет совсем уж невозможно, и этот шабаш будет продолжаться по кругу пока "ишак не сдохнет". Весь аутсорс, например, вообще так по жизни работает - в этом его суть.
Ну и что - платят за это 10х?
Хм. А решение-то разве верное?
Вы даже если к двум монетам задачу сведете, которые окажутся разного веса, то всё равно еще будет неизвестно какая именно из них фальшивая. Может я сейчас туплю просто.
UPD. А, впрочем, понял, да.
А во что они должны превратиться - в покатушки на самокатах с лавандовым смузи?
Ну, хорошо, (даже если оставить в стороне ценность вашей задумки в целом), но зачем тут вообще Unity сейчас - вы можете объяснить? "То что мертво умереть не может" (с)? Его почти никто не использовал даже когда он был живой, а сейчас у него даже последнему коммиту в его репозиторий, по-моему, уже больше пяти лет :)
Всё правильно, но, по пункту №2 - "netstandard" уже давно "deprecated" и его следует использовать только если нужна совместимость с совсем уж старыми (до .NET 5) framework-ами. А так, следует либо указывать самый старый поддерживаемый (например net6.0), либо, если имеет смысл, то перечислять несколько, например, если хочется или нужно для разных TFM написать разный код или задать разные свойства MSBuild в *.csproj файле.
Можно (и, как правило, нужно) в дополнение к "saga" и "compensating" использовать еще "transactional outbox". Но, опять-таки, это тоже дополнительное усложнение - вам уже придется не просто брать и отправлять сообщение второму сервису, а встраивать в первый еще какой-то планировщик, который будет по таймеру проверять этот "outbox" на наличие записей и отправлять во второй сервис сообщение до тех пор пока тот явно ответным сообщением не подтвердит, что он его обработал. А тут уже возникают еще новые вопросы, например, как подбирать интервал этого таймера чтобы и задержка в синхронизации данных сервисов была приемлемой, но при этом не перегружать брокер потоком одинаковых сообщений, или, например, следует ли установить какой-то лимит на количество повторных попыток, или нет. И т.д. и т.п.
Как вариант (что, по личному опыту, на самом деле, обычно и делают :) это вообще по сути забить на всё это, списав на то, что подобные ситуации (какой-то сервис, или брокер, или какая-нибудь из БД, или всё вместе, просто взяло и тупо внезапно упало в самый неподходящий момент) они всё-таки нетипичны и, в случае чего, админы вместе с поддержкой руками будут разруливать проблемы типа "продали клиенту несуществующий товар" или "деньги за заказ взяли, а заказ на сборку так и не поступил" и прочие, в случае возникновения таковых.
Понимаете, в чем дело. Вы, как пример, приводите простой код, который корректен только для идеального случая, когда всё идёт как задумано, а когда, вот, начинаются вопросы, "а что, если вот это, или вот то пошло не так", то даёте только общие ответы, которые выглядят просто. Но, если все эти ответы: "во первых, во вторых", и т.п., начать воплощать в вашем простом коде, то в результате на один только код потребуется штуки три таких статьи, и любой, кто на этот код посмотрит, вполне резонно скажет: "- Да ну их на... эти ваши микросервисы".
Я сам с микросервисами работаю уже больше семи лет, и мне вся идея сначала очень понравилась, но навозившись с ними за всё это время я полностью поменял к ним отношение. Право на существование они имеют, да. Если у вас проект, команда, и/или нагрузки масштабов какого-нибудь Netflix. В остальных случаях ну его в пень - выгода от них даже если есть, то и на доли процента не покрывает всего дрочева, связанного с их реализацией (при условии если реализация не полное го*но - но это уже отдельная тема).
И еще вы заблуждаетесь насчет "eventual consistency" и "saga". Потому что "saga" это как раз только "eventual" consistency и есть. Если вам нужна "полная" consistency, то вам нужна не saga, а "2PC" (two-phase commit) с распределенными блокировками, а это настолько сложно в реализации (опять-таки если делать всё правильно), что я даже никогда и не слышал, чтобы кто-то в реальности с этим связывался.
ASP.NET (не Core) с .NET Framework 4.8 в 2025 году? Вы серьезно?
А может вам к специалисту соответствующего профиля?
Мексиканский каток