2009-04-01 2 views
4

Я работаю над приложением .NET 3.5 со слегка сложным поведением. Это для книжного инвентаря. Чтобы дать Вам идею, рабочий процесс будет:MVP на полусложных страницах

  • Пользователь вводит код ISBN
  • Если ISBN действительно, проверить, существует ли оно,
  • Если он действителен, и он существует, подробности о книге и включите кнопку сохранения, если нет, нажмите кнопку «добавить книгу»,
  • Если это неверно, сообщите об ошибке,
  • В конце концов, пользователь нажмет кнопку «сохранить», поэтому запись должна быть сохранена.

Это четыре обязанности:

  • Validate ISBN,
  • Проверить наличие книги,
  • Показать детали книги,
  • Сохранить новая книга детали.

Мой вопрос: Должен ли я хранить логику приложения в одной MVP-структуре или я должен разделить ее на четыре MVP-структуры, по одной на каждую ответственность?

Держа это в одном MVP-структуре будет

  • сделать модель более сложной
  • сделать установку испытания более сложным (много коды настройки для каждого теста, чтобы выбрать правильный валидатор, вернулся книга и т.д. даже если они не используются),
  • сделать презентацию логики легче следовать

Держа его в отдельных ПМК-структур будет

  • сделать модель проще,
  • создать больше, но более простые тесты для каждого ведущего,
  • положить сложность взаимодействия между докладчиками (как бы я сигнализировать выступающий, что ISBN действительно так, что детали книг могут показать)

Я пытаюсь для первых принципов Presenter, так: - Держите вид немой (поэтому никаких событий, как «Presenter один заверило ISBN»), - Держи докладчик без гражданства, - Держите модели простыми (достаточно)

У кого-нибудь есть идея, что это лучший способ сделать это?

ответ

1

Я бы пошел с одним презентатором, но делегировал валидацию и т. Д. Номеров ISBN на службу.

Что-то вдоль этих линий в предъявитель для обработки ISBN вводимой:

public void IsbnEntered() 
{ 
    var isbn = view.Isbn; 

    if (isbnService.NumberIsValid(isbn)) 
    { 
     var details = isbnService.RetrieveDetailsForIsbn(isbn); 

     if (details != null) 
     { 
      view.Display(details); 
      view.EnableSaveButton(); 
     } 
     else 
     { 
      view.DisplayError("ISBN could not be found"); 
     } 
    } 
    else 
    { 
     view.DisplayError("Invalid ISBN"); 
    } 
} 

Здесь обязанности четко определены.IsbnService отвечает за обработку ISBN, представление для отображения и ввода данных, а ведущий управляет взаимодействием между ними.

+0

Это мой текущий подход (за исключением того, что у меня есть отдельный верификатор isbn и загрузчик объектов), но это, конечно, означает, что я должен инициализировать все виды макетных сервисов для проверки этого поведения в презентаторе, даже если некоторые из них никогда не использовался. Это быстро стареет :) Любая идея? – Lennaert

+0

У меня был бы отдельный верификатор и загрузчик, но в этом примере он немного упростился. Вы могли бы использовать автомодельный контейнер http://www.lostechies.com/blogs/joshuaflanagan/archive/2009/02/03/auto-mocking-explained.aspx, так как это создаст все необходимые вам зависимости, тогда у вас есть только чтобы ... –

+0

беспокоиться о том, чтобы настроить макеты, которые вы фактически будете использовать в своем тесте, другие будут созданы для вас и никогда не будут использоваться. Наряду с типом теста AAA это значительно упростило мои тесты. Другой подход, который я использовал, - это тестовый базовый класс для каждого контроллера, тогда вы только устанавливаете зависимости один раз. –

 Смежные вопросы

  • Нет связанных вопросов^_^