Здравствуйте, rsn81, Вы писали:

R>Объясните, пожалуйста, требование отсутствия событий в модели. Пока не имею возможности ознакомиться со статьей, но обязательно прочту в скором времени.
Это не требование, это рекомендация. Обоснована она тем, что часть функционала, который в классическом MVC лежит на модели, в MVP переведен в Presenter, а так же целями, которые стоят при реализации View — в статье об этом сказано более подробно.

R>К чему такие сложности?
Наличие оповещения View Моделью, устанавливает сильную зависимость View от модели и вообще усложняет View, чего хотелось бы избежать, а в некотрых случаях с оповещением вообще может быть бедулька, например, если одним из View является web-приложение. Впрочем, все зависит от ситуации, повторюсь, это всего лишь рекомендация. И об этом опять-таки сказано в статье..

R> Мне кажется правомерным замечание о двух View, которые должны получать события от одной и той же Model.
Несколько View, как правило, обслуживаются одним Presenter-ом, View меняется гораздо чаще чем Presenter.

R> Использование типизации классов ядра MVC значительно упрощает дальнейшую разработку на его основе.
Ну, это уже ортогональный аспект, все зависит от конкретной задачи, иногда действительно удобно использовать подобную параметризацию, но на суть паттерна это не влияет.