Я работаю над приложением .NET 3.5 со слегка сложным поведением. Это для книжного инвентаря. Чтобы дать Вам идею, рабочий процесс будет:MVP на полусложных страницах
- Пользователь вводит код ISBN
- Если ISBN действительно, проверить, существует ли оно,
- Если он действителен, и он существует, подробности о книге и включите кнопку сохранения, если нет, нажмите кнопку «добавить книгу»,
- Если это неверно, сообщите об ошибке,
- В конце концов, пользователь нажмет кнопку «сохранить», поэтому запись должна быть сохранена.
Это четыре обязанности:
- Validate ISBN,
- Проверить наличие книги,
- Показать детали книги,
- Сохранить новая книга детали.
Мой вопрос: Должен ли я хранить логику приложения в одной MVP-структуре или я должен разделить ее на четыре MVP-структуры, по одной на каждую ответственность?
Держа это в одном MVP-структуре будет
- сделать модель более сложной
- сделать установку испытания более сложным (много коды настройки для каждого теста, чтобы выбрать правильный валидатор, вернулся книга и т.д. даже если они не используются),
- сделать презентацию логики легче следовать
Держа его в отдельных ПМК-структур будет
- сделать модель проще,
- создать больше, но более простые тесты для каждого ведущего,
- положить сложность взаимодействия между докладчиками (как бы я сигнализировать выступающий, что ISBN действительно так, что детали книг могут показать)
Я пытаюсь для первых принципов Presenter, так: - Держите вид немой (поэтому никаких событий, как «Presenter один заверило ISBN»), - Держи докладчик без гражданства, - Держите модели простыми (достаточно)
У кого-нибудь есть идея, что это лучший способ сделать это?
Это мой текущий подход (за исключением того, что у меня есть отдельный верификатор isbn и загрузчик объектов), но это, конечно, означает, что я должен инициализировать все виды макетных сервисов для проверки этого поведения в презентаторе, даже если некоторые из них никогда не использовался. Это быстро стареет :) Любая идея? – Lennaert
У меня был бы отдельный верификатор и загрузчик, но в этом примере он немного упростился. Вы могли бы использовать автомодельный контейнер http://www.lostechies.com/blogs/joshuaflanagan/archive/2009/02/03/auto-mocking-explained.aspx, так как это создаст все необходимые вам зависимости, тогда у вас есть только чтобы ... –
беспокоиться о том, чтобы настроить макеты, которые вы фактически будете использовать в своем тесте, другие будут созданы для вас и никогда не будут использоваться. Наряду с типом теста AAA это значительно упростило мои тесты. Другой подход, который я использовал, - это тестовый базовый класс для каждого контроллера, тогда вы только устанавливаете зависимости один раз. –