Самый правильный способ перенаправить страницу с шаблоном Model-View-Presenter - PullRequest
5 голосов
/ 15 января 2010

Каков наилучший способ вызвать Response.Redirect в шаблоне Model-View-Presenter при соблюдении правильного разделения уровней?

Ответы [ 4 ]

6 голосов
/ 22 января 2010

Один способ, которым я обработал это, состоит в том, чтобы докладчик вызывал событие (например, Succeeded или что-то в этом роде), на которое будет подписываться представление. Когда докладчик заканчивает свою обработку, он вызывает событие, которое обрабатывается представлением. В этом обработчике представление будет перенаправлено на следующую страницу.

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

4 голосов
/ 24 января 2010

Я не знаю, концептуально ли это самый правильный путь. Но то, что я делал в моих последних MVP-приложениях, это создание оболочки вокруг HttpContext.Current, которую я назвал HttpRedirector. Я также создал фиктивный редиректор для тестирования. Оба отслеживают последний перенаправленный URL, так что я могу проверить в своих модульных тестах, что перенаправление действительно произошло, когда я вызываю метод на моем контроллере / презентаторе. С помощью IOC-контейнера я могу переключить реализацию IRedirector в зависимости от среды (производство / тестирование).

1 голос
/ 15 января 2010

Зависит от того, насколько универсальны ваши докладчики.Если ваши докладчики полностью независимы от пользовательского интерфейса (могут использоваться повторно между WinForms и WebForms), вам придется абстрагировать операцию перенаправления.В WebForms операция перенаправления будет реализована в представлении Response.Redirect.В WinForms, (я отказываюсь от большого опыта работы с WinForms), я предполагаю, что это будет реализовано SomeForm.Show.

Один простой вариант, который должен быть в моей голове, будет включатьв интерфейсе представления метод ShowViewX ().Вы можете иметь один для каждой формы, которую логически может перенаправить представление.В качестве альтернативы, представление может реализовывать метод интерфейса, такой как Show (ConnectedViews), где ConnectedViews - это перечисление, которое включает значение для каждого из представлений, которые могут быть «перенаправлены» из конкретного представления.Это перечисление будет жить на уровне презентатора.

Вышеуказанные подходы характерны для пар вид-презентатор.Вместо этого вы можете реализовать его как общесистемную вещь.Логика будет аналогична приведенной выше, реализована в базовом представлении и презентере.Для каждой формы будет ShowView __ () или метод Show (Views), где Views - это перечисление всех форм.

Это вызов между инкапсуляцией и DRY-ness.

1 голос
/ 15 января 2010

То, как мы это делаем, работает хорошо, когда закладывается какая-то почва. Я уверен, что есть несколько способов снять кожу с кошки. (В любом случае, кто скинет кошек. Кошки милые и приятные!)

Во-первых, это будет работать только с веб-проектами, скомпилированными ASP.Net, а не с веб-сайтами.

Каждая страница должна наследоваться от пользовательского абстрактного базового класса, который выглядит примерно так:

public abstract class PageBase : Page
{
  private static string _baseUrl = "/";

  public static string BaseUrl
  {
    get { return _baseUrl; }
    set { _baseUrl = value; }
  }

  protected static string BuildUrl(string basePath)
  {
    if( !string.IsNullOrEmpty(basePath) && basePath.StartsWith("~/"))
    {
      basePath = basePath.replace("~/", BaseUrl);
    }
    return basePath;
  }

  protected static string LoadView(string path)
  {
    Response.Redirect(path);
  }
}

Каждая страница также реализует специфичный для страницы интерфейс. Каждый специфичный для страницы интерфейс также наследуется от базового интерфейса:

public interface IPageBase()
{
  void LoadView(string path);
}

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

Наконец, любой из ваших докладчиков (которые должны ссылаться на интерфейсы для конкретной страницы) может получить статический BuildUrl () на нужной странице для просмотра, а затем вызвать LoadView () с возвращенным путем.

...