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

Question

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

Особенно, когда страница начинает заполняться 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 или отправляя их в представление. Например, если вам нужно обновить электронную почту или выполнить бизнес-логику, попробуйте выделить их в отдельные классы. Я часто сталкиваюсь с одной и той же проблемой и пытаюсь перенести как можно больше логики в отдельные классы домена / сущности и выполнить там проверку.

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