Понятно что каждому инструменту — своё применение. Я сейчас про личный опыт говорил. Нам полный лог — нужен. Но добровольно вставлять себе палки в колёса с собиранием состояний сущности из команд я не рискнул. Но помимо лога, разделение логики приложения на команды имеет и другие плюшки всё же.
Event sourcing действительно имеет огромную плюшку — полная и качественная история изменений сущности. Но вот почему светлые умы осознанно решили усложнить себе жизнь и восстанавливать состояние объектов исключительно по цепочке событий, попадая на всевозможные «любое единожды происшедшее события необходимо поддерживать навечно» и «отписался от новостей, а затем подписался… и так раз 50 (на протяжении года)» — не пойму.
Что мешает иметь поток событий, но при этом по старинке изменять и сохранять состояние соответствующих сущностей системы?
Да что там конструкция. Вы крайне негативно отозвались о реализации, сделав большое кол-во неверных утверждений, в то время как лежащий на поверхности правильный ответ вы явно проигнорировали. Ну банально нельзя так, невежливо.
Fluent-интерфейсы возвращают ссылку на промежуточный объект (скорее всего всегда новый), постепенно добавляя туда разнообразные флажки. И данный объект имеет метод, разворачивающий флажки в то, что нам нужно. В данном случае, что очевидно, это будет ToString() и\или оператор перевода в строку.
Исходя из ваших утверждений, с подобным подходом вы не знакомы.
Почему же тогда вы позволили себе быть столь категоричным, даже не заглянув за ответами в код?
При создании программного RAID10 важную роль играет выбор layout (схема физического расположения chunk'ов на дисках). near (по-умолчанию) даёт указанную в статье скорость чтения, а far — позволяет догнать RAID0:
/dev/md127:
Timing buffered disk reads: 1624 MB in 3.00 seconds = 540.49 MB/sec
Когнитивный диссонанс. В приветствии про собеседования и «Декоратор», а в статье — про реализацию стратегии. И каков же ответ на вопрос, почему вы ходите на собеседования ради фана? Кто здесь?
MVC абстрактный паттерн, но не слишком. Он конкретным образом бьёт наше приложение на вполне себе явные модули. Которые внутри уже могут быть реализованы хоть с использованием СУБД, хоть ORM (на примере модели). Просто одной статьи из Википедии недостаточно, чтобы понять данный паттерн.
А по поводу статьи — я с ней не спорил. По-моему в ней просто расписаны способы, как можно извратить изначальную концепцию. Но только практически все примеры из неё — это уже не MVC. Только в воображении авторов кода. ИМХО.
Если вы так сделаете — то действительно, логика вашего приложения будет размана от клиента и аппликейшне сервера до самой СУБД. И валидация в том числе. Можно пойти ещё дальше и в коде приложения валидировать считанные из СУБД данные. И на клиенте, после загрузки страницы, заодно проходить валидатором. А потом! Можно в коде каждого метода добавить проверки на входные данные и бросать исключения, если что-то не так. И заодно проверять инварианты\выходные данные от методов! Ващеее, идеальный проект.
Я бы поспорил на счёт раскидывания некоторых задач по элементам системы, в т.ч. ту же валидацию. Её нельзя проводить ограничениями в СУБД. И нельзя — на объектах ORM. Какой смысл пропихивать кривой ввод с представления, через контроллер и модель — в СУБД? Терять контекст в случае фейла и затем протаскивать ошибку обратно через всё это счастье? И заодно потерять гибкость на 1% задач, где временно необходимо проигнорировать консистентность данных на время выполнения запроса. Нет, валидацию нужно производить максимально близко к входу, а именно в браузере и контроллере. Каждой задаче — своё конкретное место: View, Controller или Model. Просто не нужно забывать, что всё это счастье крутится внутри некоторой исполняемой среды и нужна прослойка между миром приложения и суровым внешним миром. Обычно это называют инфраструктурой, которая неявно пронизывает каждый из модулей\слоёв\уровней. Именно там и живут задачи, которые кажется что не имеют чёткого места. И все абстракции встают на свои места.
Кстати, вопрос специально всё же сформулирован «нечётко что ли». Я сам поступаю так на собеседованиях. Да, на хорошо сформулировав вопрос я с большей вероятностью получу верный ответ. Но моя цель — не получить верный ответ, а проверить пригодность конкретного человека на конкретную позицию. Мне не нужны шаблонные ответы на шаблонные вопросы. Хочется понять, сможет ли кандидат в условиях невозможности постоянной коммуникации с коллегами, нехватки точности и непротиворечивости в требованиях и целях задачи сопоставить в голове все варианты, их плюсы-минусы и осознанно найти компромисс. И можно ли будет доверять выбранному решению, т.к. не всегда есть время отмести его в зачатке.
Что мешает иметь поток событий, но при этом по старинке изменять и сохранять состояние соответствующих сущностей системы?
Исходя из ваших утверждений, с подобным подходом вы не знакомы.
Почему же тогда вы позволили себе быть столь категоричным, даже не заглянув за ответами в код?
Если кому интересно углубиться в подробности, то есть объяснение с картинками и тестами.
MVC абстрактный паттерн, но не слишком. Он конкретным образом бьёт наше приложение на вполне себе явные модули. Которые внутри уже могут быть реализованы хоть с использованием СУБД, хоть ORM (на примере модели). Просто одной статьи из Википедии недостаточно, чтобы понять данный паттерн.
А по поводу статьи — я с ней не спорил. По-моему в ней просто расписаны способы, как можно извратить изначальную концепцию. Но только практически все примеры из неё — это уже не MVC. Только в воображении авторов кода. ИМХО.