Здравствуйте, <Аноним>, Вы писали:


А>а также для ввода от пользователя каких-либо значений или получения команд.
В оригинале за ввод отвечает контроллер, но в MVP таки да, все все равно проходит через View.

А>Вот у меня некоторая терминологическая размытость образовалась.. Занимаюсь этими вопросами недавно – читаю, размышляю и т.п.
А>Например, как понятия MVC, MVP соотносятся с с понятиями Use-Case Controller, Session Controller, Application Layer или фасадом модели предметной области?
А>Можно ли под MVP понимать Use-Case Controller или Session Controller? Или Use-Case Controller – один из вариантов MVP. Или может это совсем разные вещи?
Если говорить об MVC, то Session Controller или Use-Case Controller — это лишь один из возможных типов Controller-а (Presenter-а), то есть не всей триады, а лишь одной из ее частей. Какой из вариантов контроллера применить — зависит от конкретной задачи. Application Layer — это слой приложения отвечающий за бизнес-логику, в случае MVC/P — это все что не входит во View, хотя в некоторых случаях под этим понимается исключительно модель/и. Фасад модели предметной области — так же зависит от типа приложения и применяемого паттерна, в случае MVC это, как правило, самостоятельная сущность (Медиатор), которая является посредником между контроллером и нижележащей моделью. В случае же MVP эту обязанность берет на себя Presenter.

А> MVP как обращается к объектам модели – напрямую или через фасад/контроллер в роли которого может выступить Use-Case Controller или Session Controller?
См. предыдущий ответ. Presenter и есть Session или Use-Case контроллер, если, конечно используется такой тип Presenter-а, поэтому здесь по определению никакого посредника нет. Если же реализуется "классический" MVC, то как правило между Controller-ом (Session, Use-Case, Facade или каким-то другим) есть еще некий медиатор, который и общается с моделями.

А>Допустим у нас есть некоторый прецедент «Оформить покупку», который включает другой прецедент «Произвести аутентификацию». Причем сначала пользователю нужно аутентифицироваться, а потом производить дальнейшие действия.
Это не входит в зону ответственности данного паттерна, он лишь помогает разделить части системы, а уж что в вашем приложении к какой части системы относится, вопросво многих случаях однозначного ответа не имеющий. Однако в случае аутентификации основные проверки всегда должны быть на уровне бизнес-логики, а во view толко дубляж для удобства пользователя.

А>Еще вопрос: если контент формы FormView разнести на две разные формы <...>
А>(в одной вводятся значения по фаренгейту, в другой – по цельсию), нужно ли интерфейс IView и класс Presenter также делить на две части?<..>
Зависит от, как в конкретном случае удобнее, так и надо делать. Это уже особенность конкретного приложения а не свойство паттерна. Например известны реализации, когда каждый отдельно взятый контрол представляет собой триаду MVP. Или еще более сложный случай — помимо того, что каждый отдельный контрол MVP, набор таких контролов реализует подсистему, которая тоже MVP и View этой подсистемы как раз и содержит эти контролы, а подсистема, в свою очередь, является частью VP основного приложения. При этом иерархия может быть и выше и варианты реализации разные, со связью через View/Presenter или только через Presenter — см. паттерны Hierarchical Model-View-Controller (HMVC) и Presentation-Abstraction-Control (PAC).