MVC: грамотная архитектура проекта

[Dukobpa3]

Сообщение от Wolsh

Мне, признаться, не очень понятны медиаторы.

А в чем конкретно вопросы и что не понятно на практике?
Медиаторы становятся понятными когда используется тяжелая составная вью. Например какая-то изометрическая карта города.
Тогда удобнее сделать несколько вьюх, и все их объединить одним медиатором. Банально улучшается управляемость кода, классы меньше и лучше инкапсулированы. Но это возможно не совсем удачный пример так как его можно разрулить и просто грамотной организацией самой вьюхи.

Или второй хороший пример когда есть набор одинаковых вьюх. Тогда управление ими вынести в медиатор. Например какой-то медиатор окон или попапов. Попапов много, но с точки зрения системы - сущность одна, и это медиатор.

Еще один бонус медиатора в том что вьюхи еще тупее и еще легче заменяемые.
С точки зрения системы - вью - это медиатор. А собственно вью - это просто арт (какой-то подгружаемый мувик, например).
С таким подходом круто делать скинуемые системы. Но не в том плане скинуемые что просто шкурку поменять, а более наворочанные.
Как в каком-то казино слотмашины - игра одна, игровая логика у всех машин одинаковая, но самих машин много, и все они чем-то да отличаются, уже в понятие скину не вписывается, просто шкуркой не обойдешься. И вот эти отличия между машинами сглаживает медиатор, либо набор медиаторов.
А система этого всего не видит. Она видит только медиатор.

//********************
Это примеры из моей практики, либо, как с изометрической картой - проблемы, с которыми столкнулся, но на тот момент решил кривовато, ибо не догадался использовать медиатор.