Какова хорошая практика для разделения докладчиков в шаблоне интерфейса MVP, который стал слишком большим?

Question

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

Особенно когда страница начинает заполняться элементами управления, ориентированными на CRUD.Иногда я разделяю элементы управления, но если на них влияют другие элементы управления, логика координации сложна сама по себе.Иногда я разделяю поиск данных по спискам или сетке, но иногда это может иметь похожие подводные камни.

Существуют ли какие-либо методы, или эмпирические правила, или общие области, которые вы реорганизуете у своих докладчиков?

Answer 1

Обычно я использую два подхода:

1. Извлекайте и делегируйте бизнес-правила классам домена.
2. Разделите представление на логически связанные элементы управления, затем создайте новый интерфейс представления для каждого раздела.Затем вы можете разделить своего докладчика по тем же линиям.Если используемая вами платформа поддерживает группы компонентов подчиненных форм (пользовательские элементы управления C #, фреймы Delphi и т.д.), Это мощный способ создания повторно используемых элементов управления.

Обновить

При разделении представлений я обычно начинаю с разделения интерфейса и реализации моей формой нескольких интерфейсов.

public class ComplexForm: Form, ISubView, IOtherSubView
{
    ...
}

Затем я разделил презентацию на любое количество созданных мной просмотров.

public class SubViewPresenter
{
    private ISubView subView;
    ...
}

public class OtherSubViewPresenter
{
    private IOtherSubView otherSubView;
    ...
}

Вы можете пойти еще дальше и перенести реализацию ISubView и IOtherSubView в пользовательские элементы управления или оставить все как есть.Если вы используете пассивный просмотр шаблон это детская забава, поскольку форма в любом случае обрабатывает только логику пользовательского интерфейса.Как только я разделяю ведущего, я стараюсь избегать прямого общения между ведущими.Если требуется какая-либо коммуникация, я стараюсь делать это косвенно, через доменные объекты.

Answer 2

Попробуйте извлечь код, который выполняет действия, не передавая данные в ваш DAL или отправляя их в представление. Например, если вам нужно обновить электронную почту или выполнить бизнес-логику, попробуйте выделить их в отдельные классы. Я часто сталкиваюсь с одной и той же проблемой и пытаюсь перенести как можно больше логики в отдельные классы домена / сущности и выполнить там проверку.

Надеюсь, это полезно.