В MVP как решается сложность модели данных и где динамически показывать / скрывать элементы управления? - PullRequest
Новая
       25

В MVP как решается сложность модели данных и где динамически показывать / скрывать элементы управления?

1 голос
/ 03 августа 2011

В большинстве примеров MVP, которые я видел, докладчик вызывает какую-то службу, которая вызывает некоторое хранилище, которое возвращает сущность. В большинстве веб-приложений asp.net, над которыми я работал, логика никогда не бывает такой простой. В моем последнем проекте мой докладчик назвал слой службы докладчика, который должен был прыгать через обручи, чтобы получить данные, которые должны были отображаться на экране.

Подробности: сервисный уровень запрашивает базу данных, скажем, о 8 объектах сущностей, некоторые из которых вложены друг в друга, затем код отображает эти сущности в одну огромную базу объектов вне XSD. Затем этот объект xsd был передан сторонней библиотеке, чтобы что-то с ним сделать. После того, как он вернул обработанный объект xsd, код должен был проанализировать этот объект xsd, используя класс средства форматирования представления среднего уровня, чтобы извлечь и построить то, что я называю «моделью представления» (я слышал, некоторые называют это DTO). Затем эта модель представления была возвращена из уровня обслуживания докладчику, а затем привязана к ретранслятору.

  1. Куда идет логика управления показом / скрытием? Должен ли он быть членом DTO или докладчик должен получить это значение? (Я выбрал его в качестве члена модели представления)
  2. Можно ли использовать вложенные ViewModels (DTO) или следует использовать другие пользовательские элементы управления для уменьшения сложности?
  3. Как правильно связать докладчика со всеми страницами / пользовательскими элементами управления, которые его используют; имеется в виду один докладчик с 5 IViews, которые требуют того же экземпляра докладчика. Должны ли пользовательские элементы управления быть автономными или они должны полагаться на «родительский» IView (страницу), чтобы предоставить ему надлежащего докладчика?

  4. Вместо того, чтобы иметь модель представления, почему бы просто не использовать интерфейс, который реализует Страница, и передать его на сервисный уровень (через презентатора) и позволить сервису увлажнять IView? (Это может привести к тому, что сервисный уровень будет иметь ссылку на него, не так ли плохо?). 

    public class ViewModel
{
    public bool ShowHeight { get; set; }
    //Is there a bettter way to do this?
    public List<NestedViewModel> NestedViewModel { get { return _nestedViewModel; } }
}

1 Ответ

2 голосов
/ 03 августа 2011
  1. IMO, представление должно управлять отображением и скрытием;это представление и отвечает за управление поведением пользовательского интерфейса.
  2. Я думаю, что сложность в порядке, пока она не слишком властна;при необходимости вы можете разбить его на вложенные подпредставители / представления.
  3. Большинство платформ MVP заполняют отношение презентатор / представление из представления, тем более что ASP.NET выполняется в контексте страницы (страницаобработчик HTTP, обрабатывающий запрос, так что это то, что живо на данный момент).Страница, во время инициализации, идет и устанавливает отношения представления / докладчика.Большинство примеров делают это так.Я построил инфраструктуру MVP и также установил этот подход.
  4. Вы могли бы;это считается пассивным представлением, хотя докладчик все равно должен выполнять работу, а не напрямую переходить на уровень обслуживания.

Это мое мнение, и для этого есть много способов.

...