MVP - должен ли докладчик использовать сессию?

Question

Я использую шаблон Model-View-Presenter для веб-страницы. Должен ли докладчик знать о сеансе или о нем должен знать только вид?

Полагаю, я понимаю, что такие понятия, как Session, очень связаны с архитектурой представления, поэтому должны ли они быть ограничены для использования представлением? Иначе, что произойдет, если я захочу повторно использовать докладчика на аналогичной странице в другой архитектуре (или мне не нужно беспокоиться об этом, если у меня нет планов сделать это)?

Answer 1

Я делаю что-то вроде этого в своей реализации MVP. Я внедряю в мой презентатор ICookieManager, ISessionManager, ICacheManager, IConfigurationManager, IRedirector, которые реализуются классами, которые обертывают для этого функциональность.

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

Приветствия

Answer 2

Это может быть даже общий модуль, который действует как оболочка для любого сеанса, который вы используете. Таким образом, он будет доступен для всех ваших контроллеров, и вы сможете просто изменить физическую реализацию сеанса.

Ваш докладчик будет заполнять представление всем, что контроллер извлекал из сеанса.

Answer 3

Спасибо за ваши ответы всем, так что подведу итоги ...

Мы говорим, что на самом деле Presenter должен иметь возможность доступа к данным из сеанса (предпочтительно через интерфейс) и, по его мнению, не должен получать к ним доступ (оставаясь тупым)?

Answer 4

Совет состоит в том, чтобы взаимодействовать с каждым расходуемым объектом. Это облегчает тестирование докладчика и модели с помощью насмешек и фокусирует тесты на поведении.

Answer 5

Я также исследую пассивные подходы MVP. Я видел несколько вещей, сделанных в сети, которые оставляют постоянство сеанса вплоть до представления - либо путем внедрения, как упоминал голубь, либо с помощью явного управления.

Примеры внедрения зависимостей можно увидеть здесь: http://www.codeproject.com/KB/aspnet/Advanced_MVP.aspx и здесь: http://geekswithblogs.net/opiesblog/archive/2006/06/30/83743.aspx. Хитрость заключается в том, чтобы управлять всеми экземплярами сеанса в статической переменной и предотвращать их перезапись друг друга. (Я не уверен, что первый пример выполняет это правильно.)

Второй подход здесь: http://codebetter.com/blogs/jeffrey.palermo/archive/2005/03/28/128592.aspx. В этом примере представление знает, как сохранить свое состояние. Недостатком является то, что каждый раз, когда докладчик помещает данные в представление, он должен вызывать метод Update в представлении для принудительного повторного связывания. В приведенных выше примерах это не требуется, но вам не нужно управлять таблицей сеансов. Я не уверен, насколько этот подход усложняет тестирование с помощью инструментов для насмешек.

Answer 6

Да, как говорит голубь, заверните все, что обращается к Сессии, в другой класс.

Это означает, что вы можете внедрить фиктивный класс этого типа для имитации различных значений для сеанса.

Чтобы ответить на ваш вопрос более конкретно, я стремлюсь к паттерну Supervising-Presenter (http://martinfowler.com/eaaDev/SupervisingPresenter.html),, который делает Представления ОЧЕНЬ тупыми. Таким образом, только докладчик будет иметь доступ к сеансу (хотя и не так, как я сказал) до) и скажите View, что делать.

Answer 7

Зависит от того, какой объект вы пытаетесь использовать повторно или иным образом содержит большую часть бизнес-логики.

Я бы предположил, что только докладчик должен знать о сеансе, поскольку этот объект является ближайшим к контроллеру в MVP.