Представьте, что у вас есть функция из сторонней библиотеки. И функция эта не предоставляет расширения своей логики. Это обычная функция. Если захотите модифицировать лоику, как будете это делать? Разве что IL реврайтинг.
Если обьект задизайнен так чтобы не показывать свои данные, то он так задизайнен. Значит автор обьекта готов показывать только тот контракт который показан. Очевидно же. Именно под этот юзкейс заточена реализация, протестированна и потдерживаеться. Все остальное придумки. Вы же не ожидаете что ООП обьект автоматически начнет работатть в Ремотинге? Или то что обьект станет транзакционным, или будет генерить евент стримы.
В том же DDD есть течения кторые вообще отказываються показывать данные. Тоесть ентити содержит только методы! И да, обьект и продолжает оставаться POCO, и продолжает укладываться в парадигму ООП.
> Если следовать принципам DDD и SOLID, то часть системы, содержащая бизнес логику вообще ничего не должна знать о способе хранения. Это должны быть обычные POCO (в случае С#) классы.
Паттерн Memento как раз и отвязывает бизнес логику от знания о способе хранения. Memento вообще не говорит именно о том что данные предоставляються для хранения, данные вполне могут использоваться где угодно, например в аудите.
Если хотите доказать обратное, давайте ссылки на доказательства.
П.С. И бизнес классы получаються самые что не есть обычные POCO.
П.П.С. Как только вы согласитесь что Мементо не нарушает SRP, мы можем перейти к доказательству что мапинг при помощи рефлекшена, это просто реализация Мементо, а не какие-то там бубны.
Memento это не паттерн сохранения данных, это паттерн предоставляения данных.
Когда вы говорите про нарушение SRP, вы всегда указывайте что вы под этим имеете ввиду. Есть как минимум десяток вариантов:
1. Хранение данных отдельная респонсибилити, поэтому в класе не может быть еще респонсибилити поведенения
2. Или храниене данных это не отдельная респонсибилити, но обьедениение двух поведений считаеться нарушением SRP
3. Или как в практиках DDD, у ентити респосибилити это обслуживание одной бизнес сущьности. Тоесть все что связано с этим обслуживание не нарушает SRP.
Если вы говрите про SRP как одно из первых двух, то это ваши проблемы, и я не смогу вас переубедить. Если же вы согласны на третее определение, то как только вы почитаете чем отличаеться Memento и Active Record, вы поймете что не правы.
Тест проверяет на подтдержку кодеков для видео. ИЕ кодеки берет из системьі, поєтому например если вьі поставите коде ВебМ, то ИЕ автомато будет потдерживать ВебМ. Поєтому, на разньіх системах могут буть разнье результатьі.
Да, конфиденциальность будет потеряна — но анонимность все равно останется.
Тоесть на фейсбуке вы будете общаться с родителями под вымышленным именем, одноразовым почтовым адресом? И будете уверены что ваш Гугль не сдаст ваш IP по gmail адресу?
Проблема в том что в социалках, хочешь не хочешь, а все равно все будет известно. Поэтому с ними NSA и работает.
ZMQ может использоваться в рамках одного приложения, передача данных по ссылке это в 98% случаев минус. Даже в Вашем примере передача по ссылке не нужна.
Подход с разделением на команды(ваши сигналы) и хендлеры ипользуется уже кучу времени в .NET. Можете взяглянуть на NCQRS, можно на ICommand в WPF, NServiceBus. Даж в моем микро проектике — комманд диспатчер — github.com/chaliy/zaz. Просто задача настолько простая что никто это в отдельные библиотеки не выносит.
Бай зе вей, можете еще очереди посмотреть, с балансировкой нагрузки, распределенностью и тому подобным. Тож самое разделение, на команды и хендлеры, только между ними еще мега умный диспатчер.
Я если чесно не совсем понял чего вы хотелись добиться, поэтому могу ошибаться.
Судя по всему вы изобретаете Actor Model, в .NET уже есть куча реализаций: уже упомянутый MailboxProcessor, TPL Dataflow, ActorFX и так далее. Плюс похожие схемы легко реализуются на Reactive Extensions.
Если суть в диспатчерах (команда-хендлер) то выделенных проектов насколько я знаю нема, но есть милионы cqrs фреймворков, которые это делают. Технически это четыре строки кода (особенно если пользоваться dynamic кейвордом).
Если обьект задизайнен так чтобы не показывать свои данные, то он так задизайнен. Значит автор обьекта готов показывать только тот контракт который показан. Очевидно же. Именно под этот юзкейс заточена реализация, протестированна и потдерживаеться. Все остальное придумки. Вы же не ожидаете что ООП обьект автоматически начнет работатть в Ремотинге? Или то что обьект станет транзакционным, или будет генерить евент стримы.
В том же DDD есть течения кторые вообще отказываються показывать данные. Тоесть ентити содержит только методы! И да, обьект и продолжает оставаться POCO, и продолжает укладываться в парадигму ООП.
Паттерн Memento как раз и отвязывает бизнес логику от знания о способе хранения. Memento вообще не говорит именно о том что данные предоставляються для хранения, данные вполне могут использоваться где угодно, например в аудите.
Если хотите доказать обратное, давайте ссылки на доказательства.
П.С. И бизнес классы получаються самые что не есть обычные POCO.
П.П.С. Как только вы согласитесь что Мементо не нарушает SRP, мы можем перейти к доказательству что мапинг при помощи рефлекшена, это просто реализация Мементо, а не какие-то там бубны.
Когда вы говорите про нарушение SRP, вы всегда указывайте что вы под этим имеете ввиду. Есть как минимум десяток вариантов:
1. Хранение данных отдельная респонсибилити, поэтому в класе не может быть еще респонсибилити поведенения
2. Или храниене данных это не отдельная респонсибилити, но обьедениение двух поведений считаеться нарушением SRP
3. Или как в практиках DDD, у ентити респосибилити это обслуживание одной бизнес сущьности. Тоесть все что связано с этим обслуживание не нарушает SRP.
Если вы говрите про SRP как одно из первых двух, то это ваши проблемы, и я не смогу вас переубедить. Если же вы согласны на третее определение, то как только вы почитаете чем отличаеться Memento и Active Record, вы поймете что не правы.
А я вижу крутезный доклад, после которого мне захотелось попробовать технологию. И могу это сравнить с твоими, Саша, докладами.
Тоесть на фейсбуке вы будете общаться с родителями под вымышленным именем, одноразовым почтовым адресом? И будете уверены что ваш Гугль не сдаст ваш IP по gmail адресу?
Проблема в том что в социалках, хочешь не хочешь, а все равно все будет известно. Поэтому с ними NSA и работает.
Бай зе вей, можете еще очереди посмотреть, с балансировкой нагрузки, распределенностью и тому подобным. Тож самое разделение, на команды и хендлеры, только между ними еще мега умный диспатчер.
Судя по всему вы изобретаете Actor Model, в .NET уже есть куча реализаций: уже упомянутый MailboxProcessor, TPL Dataflow, ActorFX и так далее. Плюс похожие схемы легко реализуются на Reactive Extensions.
Если суть в диспатчерах (команда-хендлер) то выделенных проектов насколько я знаю нема, но есть милионы cqrs фреймворков, которые это делают. Технически это четыре строки кода (особенно если пользоваться dynamic кейвордом).