MVP: детальная форма, презентер и FieldManager

[Romanov]

Архитектурная ошибка — создавать экземпляр FieldManager в конструкторе DetailFormViewImpl (как мы это делаем почти везде), поскольку FieldManager — часть бизнес-логики, и он необходим именно презентеру, а не вьюшке.

Что слишком характерно, интерфейс детальной формы предусматривает это (см. DetailFormView.java: там есть методы setFieldManager и getFieldManager), но остальная часть системы не использует этот интерфейс.

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

Предлагается создавать FieldManager в презентере, и далее протягивать его в DetailFormViewImpl методом setFieldManager. Это потребует вынесения группы инструкций

fields.put(FIELD_ID, fieldWidget);
fields.put(FIELD_ID, fieldWidget);
...

из конструкторов вьюшек прикладных детальных форм в отдельный метод (bind), вызываемый после создания вьюшки. Однако этим мы только улучшим логику класса: ведь связывание виджетов с бизнес-полями — это совсем не ответственность конструктора.

[Roman Zakharov]

Правильно понимаю, что виджеты, которые сейчас объявляются в конструкторе, станут полями класса DetailFormViewImpl ?

[Romanov]

Да