Почему интерфейс?

Хотелось бы более подробно остановиться на интерфейсе IView, что дает его использование, и почему бы не заменить его на базовый класс, с некоторой примитивной реализацией...

Строго говоря, сам паттерн вовсе не обязывает использовать для представления именно интерфейс, но использование здесь именно интерфейса, на мой взгляд, дает ряд преимуществ. Прежде всего, как и завещано создателями упоминавшегося принципа IoC, подобный подход уменьшает зависимость между классами. Замена интерфейса на некоторую базовую реализацию привела бы к тому, что изменение базовой реализации могло бы нарушить правильную работу использующего эту реализацию класса, в данном случае Presenter-а.

Помимо этого, использование интерфейса дает возможность делать Представление из объектов находящихся на любом уровне уже существующих иерархий, предоставляемых готовыми библиотеками. Например, в вышеприведенном случае, вполне можно было бы сделать базовую реализацию унаследовав ее от System.Windows.Forms, но дело в том, что конкретное Представление не обязательно может являться формой, с тем же успехом это может быть и контрол и даже произвольный класс, агрегирующий в себе графические элементы, а наследование от System.Windows.Forms жестко впишет базовый класс Представления в уже имеющуюся иерархию, и лишит подобной гибкости. Более того, с применением интерфейса Представление вообще может быть реализовано не в Win, а в Web-интерфейсе, реализовав, например, интерфейс IView от наследника System.Web.UI.Page. Очевидно, применение базовой реализации вместо интерфейса, как минимум, серьезно затруднило бы такой вариант использования Представлений.

Ну и, наконец, одной из особенностей данного паттерна является, так называемая, «скромность» Представления (humble view) по Фаулеру, то есть, в Представлении содержится вообще самый минимум логики, в некоторых источниках это так же называют «ультра тонкое» представление. Вследствии этого реализация интерфейса IView, как правило, крайне примитивна, чего собственно и добивались, декларируя необходимость вынесения максимального количества логики из Представления в Presenter.

Отличия от mvc

Чем же данный паттерн отличается от «классического» MVC и почему Controller назвали Presenter-ом?

Прежде всего, можно заметить, что, количество связей между сущностями уменьшилось, как правило, в MVP Модель не общается с Представлением даже опосредовано, через механизм оповещений, но это не обязательное условие, более глубокие отличия лежат как раз в области Presenter-а.

Как уже упоминалось выше, в MVC Модель, на самом деле, является медиатором, между Контроллером/Представлением и реальной моделью домена (Domain Model) приложения. В MVP-же, что видно на схеме, такого медиатора нет и его функции берет на себя Presenter, таким образом Presenter, в отличие от Контроллера, общается непосредственно с моделью приложения, а не с неким промежуточным звеном. Это позволяет, в случае необходимости, общаться Presenter-у с Представлениями, минуя Модель приложения и событийный механизм с этим связанный, так как Presenter в отличии от Контроллера, обладает необходимыми знаниями о Представлениях, а так же удаляет лишнюю логику обработки событий от Модели из Представления.

Отдельно стоит упомянуть совместимость с существующими оболочками и средами, что являлось одним из требований к MVP. В оригинальном MVC интерфейсом ко внешним событиям является Контроллер, однако большинство существующих библиотек и сред интегрируют эту функцию в Представление, провоцируя тем самым разработку в стиле Document-View. Этот момент обходится в MVP за счет того, что все нужные Presenter-у события описываются в интерфейсе Представления, и все необходимые события возниающие в Представлении просто пробрасываются в Presenter, что позволяет вынести из Представления логику их обработки.

Вследствии этого, как уже так же упоминалось, в отличии от MVC, Представление в MVP является «скромным» или «ультра-тонким» и практически не содержит логики независимой от конкретного Представления. Эту особенность, помимо всего прочего, очень любят маньяки от тестирования типа того же Фаулера, любители TDD, продвигатели XP и прочих Agile методологий, поскольку «скромные» представления сводят код не покрытый модульными тестами к минимуму.

Иными словами, если в случае MVC Контроллер играет довольно примитивную роль вызывальщика соответствующих методов Модели при реакции на событие, то Presenter в MVP уже берет на себя ведущие функции по управлению Моделями и Представлениями. Боюсь только, что данная особенность не нашла отражения в приведенном примере.