Если у нас экземпляр B возвращает библиотека, и в рамках каких-то других действий она же меняет это B. Можем ли мы в клиентском коде записать его в immutable и что произойдет когда библиотека попробует его поменять?
Я про них не забыл. Просто убрал из внимания как мало используемые и слишком простые. Любая система которая находится вне веб зачастую очень простая и не может превращаться в достаточно сложную.
Давайте рассмотрим, например, такую не веб программы как операционные системы Windows и Linux. Можете привести мне в пример веб программы большей сложности?
Что вы имеете ввиду под «не описывающий алгоритмы»? То есть по вашему, на sql не возможно написать программу которая будет получать на вход список целых чисел и выдавать на выходе эти же числа но в порядке возрастания (алгоритм сортировки)?
Для проверки подписи нужно выполнить следующие шаги:
По полученной подписи восстановить числа r и s. Если не выполнены неравенства 0<r<q и 0<s<q, тогда вернуть «подпись не верна»;
Вычислить хеш сообщения M: H=h(M);
Вычислить целое число α, двоичным представлением которого является H;
Определить e=α mod q, если e=0, задать e=1;
Вычислить v = e-1 mod q;
Вычислить значения z1 = s*v mod q и z2 = -r*v mod q;
Вычислить точку эллиптической кривой C = z1*G + z2*Q;
Определить R = xc mod q, где xc — x-координата точки C;
Если R=r, то подпись верна. В противном случае подпись не принимается.
Этот алгоритм не безопасный.
Вы используете в самом начале делаете ранний выход из алгоритма, то есть сообщаете злоумышленнику дополнительную информацию о том, что именно не верно.
Более правильно если неравенство не выполняется взять какие-то другие числа r и s чтобы неравенство выполнялось и продолжить алгоритм до конца (естественно отметив что в результате возвращать мы будем сообщение подпись не валидна).
То есть вы хотите вообще не иметь никакой модели? В этом случае ни о какой консистентности данных говорить не приходится вообще. (Даже об eventually consistency.) Вам просто не на чем проверять эту консистентность. Нет, если ваша система хранит разрозненные данные, можно так делать, наверное, Но, боюсь, для того чтобы получить что-нибудь полезное из этой кучи, вам придется применять методы применяемые для работы с большими данными.
Начну с простого вопроса:
А почему вы решили, что для хранения состояния нужна обязательно реляционная бд? Фаулер пишет буквально следующее:
Application states can be stored either in memory or on disk. Since an application state is purely derivable from the event log, you can cache it anywhere you like. A system in use during a working day could be started at the beginning of the day from an overnight snapshot and hold the current application state in memory.
То есть можно вообще не создавать read model и кешировать в памяти доменную модель из которой и брать нужные вещи, In-memory cache можно восстанавливать по событиям при старте приложения.
Разделение на Read модель и доменную модель описывается паттерном CQRS, который хоть и хорошо сочетается с EventSourcing но все же отдельный паттерн, не требующий ни EventSourcing ни даже отдельных бд для чтения и записи.
Был у меня случай когда я использовал сущность из EF в качестве аргумента для задачи, отправленной в планировщик. Естественно, после обновления новый рантайм, и стало быть новые типы (особенность EF). Hangfire словил исключение, записал его, и так пять раз кряду, а потом забил, записав задачу как Failed. Мне, соответственно пришлось выяснить почему не работает функционал (спасибо тестерам), ну вот и закрутилось колесо дебага.
Вообще-то автор хангфаера явно и четко пишет, что не рекомендуется использовать в качестве аргументов задачи объекты сложных типов. То есть по хорошему вам нужно было передать в него идентификатор сущности а саму сущность достать из бд в рамках задачи.
Hangfire это все же не энтерпрайз шина, а пакет, встраивающий в приложение возможность управления задачами. Планировщик и несколько очередей выполнения задач.
Ну так отдельный модуль, сепарированный, не требующий поддержки, легко встраиваемый. Если все это правда — он почти не усложняет архитектуру приложения, потому что его внутренняя архитектура никак не влияет на архитектуру приложения.
Можно здесь подробней? Не совсем понятно какой тип задач в рамках ASP.NET сервера можно эффективно решать scheduler'om который привязан к таймеру, а не веб-запросу в качестве тригера.
Если делать отдельный сервис для бекграунд задач, то появляется лишняя единица развертывания. Во многих случаях это не оправданно. А типовые бекграунд задачи — посылать уведомления по расписанию или что-то подобное.
Зачем все это в хост веб приложения встраивать?
Я, честно говоря, последнее время считаю, что не нужно эти задачи встраивать в веб приложение и закладываю в архитектуру сразу отдельный сервис для бекграунд задач. Но это архитектуру усложняет и многие предпочитают хостить бекграунд задачи прямо в ASP.net приложении.
Вообще-то hangfire не такой уж и бесплатный. У него есть Pro модификация в которой сейчас собственно и идет разработка, а бесплатный вариант не развивается.
Мы можем создать произвольное количество Hangfire-серверов и не думать об их синхронизации — Hangfire гарантирует, что одна задача будет выполнена одним и только одним сервером. Пример реализации — использование sp_getapplock (см. класс SqlServerDistributedLock).
Не гарантирует. Он (при организации расписания в sql) скрывает задачу из очереди на выполнение на 15 минут (по умолчанию, настраивается) а потом она появляется снова в очереди и может быть подхвачена другим сервером (или даже тем же самым). В результате хангфаер можно использовать только как планировщик задач, а управлять транзакционностью и т.п. приходится все равно снаружи. Вот и получается, что профит относительно quartz.net невелик.
Впрочем в качестве плюса можно отметить, что hangfire хорошо встраивается в asp.net приложения, не нужно следить за бекграунд потоками, в случае рестарта хоста корректно шлются завершающие сигналы во все запущенные потоки.
Вот если каждый человек в мире будет знать квантовую физику на уровне ученых церн, то на ряду с открытостью они будут доступными.
Даже в этом случае, между открытым фундаментальным законом (ну или найденным бозоном Хиггса) и прикладным решением на котором можно зарабатывать деньги — человеко-годы разработок инженеров и миллионы потраченных денег. Так что прежде чем извлекать прибыль придется потрудится и вложится.
Вот только проблема в том, что неясно кто будет расставлять границы между разными продуктами и определять они имеют разную область применения или одну. А если области применения разные но пересекаются? В той же физике есть масса полуэмпирических формул которые прекрасно действуют (на необходимом для задачи уровне приближения), но для которых открыты более строгие законы. И эти эмпирические формулы успешно конкурируют со строгой за счет простоты при достаточной точности.
Давайте рассмотрим, например, такую не веб программы как операционные системы Windows и Linux. Можете привести мне в пример веб программы большей сложности?
Этот алгоритм не безопасный.
Вы используете в самом начале делаете ранний выход из алгоритма, то есть сообщаете злоумышленнику дополнительную информацию о том, что именно не верно.
Более правильно если неравенство не выполняется взять какие-то другие числа r и s чтобы неравенство выполнялось и продолжить алгоритм до конца (естественно отметив что в результате возвращать мы будем сообщение подпись не валидна).
А почему вы решили, что для хранения состояния нужна обязательно реляционная бд? Фаулер пишет буквально следующее:
То есть можно вообще не создавать read model и кешировать в памяти доменную модель из которой и брать нужные вещи, In-memory cache можно восстанавливать по событиям при старте приложения.
Разделение на Read модель и доменную модель описывается паттерном CQRS, который хоть и хорошо сочетается с EventSourcing но все же отдельный паттерн, не требующий ни EventSourcing ни даже отдельных бд для чтения и записи.
Вообще-то автор хангфаера явно и четко пишет, что не рекомендуется использовать в качестве аргументов задачи объекты сложных типов. То есть по хорошему вам нужно было передать в него идентификатор сущности а саму сущность достать из бд в рамках задачи.
Если делать отдельный сервис для бекграунд задач, то появляется лишняя единица развертывания. Во многих случаях это не оправданно. А типовые бекграунд задачи — посылать уведомления по расписанию или что-то подобное.
Я, честно говоря, последнее время считаю, что не нужно эти задачи встраивать в веб приложение и закладываю в архитектуру сразу отдельный сервис для бекграунд задач. Но это архитектуру усложняет и многие предпочитают хостить бекграунд задачи прямо в ASP.net приложении.
Не гарантирует. Он (при организации расписания в sql) скрывает задачу из очереди на выполнение на 15 минут (по умолчанию, настраивается) а потом она появляется снова в очереди и может быть подхвачена другим сервером (или даже тем же самым). В результате хангфаер можно использовать только как планировщик задач, а управлять транзакционностью и т.п. приходится все равно снаружи. Вот и получается, что профит относительно quartz.net невелик.
Впрочем в качестве плюса можно отметить, что hangfire хорошо встраивается в asp.net приложения, не нужно следить за бекграунд потоками, в случае рестарта хоста корректно шлются завершающие сигналы во все запущенные потоки.
Даже в этом случае, между открытым фундаментальным законом (ну или найденным бозоном Хиггса) и прикладным решением на котором можно зарабатывать деньги — человеко-годы разработок инженеров и миллионы потраченных денег. Так что прежде чем извлекать прибыль придется потрудится и вложится.