Привет)) да, я внёс некоторые изменения, мне кажется так проще понять тем, кто в первые знакомится с архитектурой.
Надеюсь ты не против того, что я таким образом решил рассказать про Composition Root. Ну и на авторство проектирования, я, конечно, не претендую. Моя цель рассказать и пообщаться со всем заинтересованными.
Спасибо за правки по статье, архитектура реально хорошая, если интересно, то можешь глянуть на рефакторинг и дать свою оценку https://habr.com/ru/articles/711140/
Из минусов могу назвать постоянное заполнение значений переменных контекстов и невозможность поиска этих значение в редакторе через "Find usage", тк контексты всегда создаются заново. Но во второй части статьи я расскажу о том как прошёл мой опыт по переходу на контексты с ссылочным типом.
Из плюсов:
Наглядная организация кода, всегда понятно что за что отвечает и какие связи нужны, незнакомый с кодом человек быстро разберётся (если конечно всё не испортить в ходе реализации)
Лёгкость масштабирования - добавляем новые сущности, объединяем со старыми при помощи контекстов
Лёгкость рефакторинга - всегда можно разделить функционал на несколько PM, передать другой сущности (если это необходимо)
Гибкая организация контекста. Например, если нужно наладить взаимодействие между классами в разных ветвях проекта, то можно включить в контекст реактивную переменную с интерфейсом класса
По началу масштабирование может показаться сложным, но по факту это простой, немного монотонный процесс (куда без них). Вся суть в правильной декомпозиции сущностей, а от них уже идём дальше. В статье и так получилось не мало кода, дописывать ещё не вижу смысла. Могу добавить, что сейчас работаю над проектом с такой архитектурой в котором уже более 50 сущностей.
Спасибо за столь объёмное ревью, постараюсь ответить кратко. Я представил базовый-схематичный каркас для архитектуры и специально в конце указал на это. В реальных проектах мы используем и ObjectPoolling и различные решения для UI и защиту "от джунов" или каких либо других ошибок. В этой статье я не преследовал цели рассказать прям обо всём что нужно, что бы проект стал мега надёжным и производительным. К таким решениям команды приходят сами, исходя из опыта специалистов. Для понимания самой сути архитектуры и возможности начать и расширить проект, этого кода вполне достаточно.
Привет)) да, я внёс некоторые изменения, мне кажется так проще понять тем, кто в первые знакомится с архитектурой.
Надеюсь ты не против того, что я таким образом решил рассказать про Composition Root. Ну и на авторство проектирования, я, конечно, не претендую. Моя цель рассказать и пообщаться со всем заинтересованными.
Спасибо за правки по статье, архитектура реально хорошая, если интересно, то можешь глянуть на рефакторинг и дать свою оценку https://habr.com/ru/articles/711140/
Продолжение статьи можно почитать вот тут https://habr.com/ru/post/711140/
Всё довольно просто и понятно, мне кажется разобраться с таким труда не составит, но автору спасибо, такие быстрые руководства бывают очень полезны
Из минусов могу назвать постоянное заполнение значений переменных контекстов и невозможность поиска этих значение в редакторе через "Find usage", тк контексты всегда создаются заново. Но во второй части статьи я расскажу о том как прошёл мой опыт по переходу на контексты с ссылочным типом.
Из плюсов:
Наглядная организация кода, всегда понятно что за что отвечает и какие связи нужны, незнакомый с кодом человек быстро разберётся (если конечно всё не испортить в ходе реализации)
Лёгкость масштабирования - добавляем новые сущности, объединяем со старыми при помощи контекстов
Лёгкость рефакторинга - всегда можно разделить функционал на несколько PM, передать другой сущности (если это необходимо)
Гибкая организация контекста. Например, если нужно наладить взаимодействие между классами в разных ветвях проекта, то можно включить в контекст реактивную переменную с интерфейсом класса
По началу масштабирование может показаться сложным, но по факту это простой, немного монотонный процесс (куда без них). Вся суть в правильной декомпозиции сущностей, а от них уже идём дальше. В статье и так получилось не мало кода, дописывать ещё не вижу смысла. Могу добавить, что сейчас работаю над проектом с такой архитектурой в котором уже более 50 сущностей.
Абсолютно согласен, DI это внедрение зависимостей, которое здесь реализовано через конструктор, что явно говорит о том, что оно есть
Спасибо за столь объёмное ревью, постараюсь ответить кратко. Я представил базовый-схематичный каркас для архитектуры и специально в конце указал на это. В реальных проектах мы используем и ObjectPoolling и различные решения для UI и защиту "от джунов" или каких либо других ошибок. В этой статье я не преследовал цели рассказать прям обо всём что нужно, что бы проект стал мега надёжным и производительным. К таким решениям команды приходят сами, исходя из опыта специалистов. Для понимания самой сути архитектуры и возможности начать и расширить проект, этого кода вполне достаточно.