Pull to refresh

Comments 4

А закончить надо было таким утверждением:

Мрак не в клозетах моделях, мрак – в головах

А теперь серьезно. Где сравнение-то? Какова цель архитектуры? Тема мрака не раскрыта.

  1. Сравнение чего с чем и по каким параметрам?

  2. Цель архитектуры - держать мрак в моделях, а не пачкать им весь остальной код.

  3. Чего не хватило для раскрытия мрака?

Первоначально данная статья задумывалась как сравнение двух реализаций (VIPER и MM) одного приложения.

Не хватило понимания, чем ММ лучше, а чем хуже.

Несколько раз пытался это подчеркнуть в статье, возможно, это не очень удалось, попробую ещё раз.

В других виденных мною архитектурных шаблонах я не встречал правила о том, где именно принимаются решения. Например, если мы говорим о VIPER, то часть решений может быть принята в Presenter, часть - в Interactor, третья - во View. В итоге решения принимаются неизвестно где и этих мест может быть сколько угодно, т.к. правила нет, всё на усмотрение программиста.

В ММ место принятия решений одно - это модель. Причём принятие решений написано в самом обычном императивном стиле, никакой асинхронщины, даже несмотря на то, что приложение реактивное. Когда место принятия решений одно, то всегда должно быть ясно, куда и что писать. Т.е. в идеале не должно возникать вопросов "Где находится X", "Куда написать X", "Где поправить X".

Sign up to leave a comment.

Articles