MVP и многопользовательские Средства управления

Question

MVP и многопользовательские Средства управления

<input type="number" id="formInputBodySize"  
oninput="fBodySize(this.value)">

<script>

function fBodySize(elInput) {
let arrBodySize = [];
arrBodySize.push(elInput);

let res = Number(arrBodySize[arrBodySize.length - 1]);

document.getElementById('titleWeight').innerText = res;
}

</script>

17

c# design-patterns oop user-controls mvp

задан SwDevMan81 4 May 2009 в 19:42

3 ответа

Каждому представлению не нужно реализовывать один и тот же интерфейс ... Почему бы не определить интерфейсы для каждого элемента управления и иметь один Presenter для всего экрана, который содержит все элементы управления? Presenter может «связывать» события в каждом представлении в соответствии с тем, какие события, определенные в интерфейсе, требуются каждому представлению, соответствующим обработчикам событий в Presenter (и на контроллере, если вы выполняете MVPC). Вам также может понадобиться другой интерфейс для представления функциональности Presenter, к которой ВСЕм представлению необходим общий доступ ...

Если вы выполняете MVPC, тогда события, которые влияют на модель, будут "обработаны" в контроллере, тогда как события View которые влияют только на другие части просмотра, будут обрабатываться на докладчике.

0

ответ дан 30 November 2019 в 12:20

Вы должны выполнять один докладчик на один элемент управления из-за:

, который позволит вам сфокусировать модульные тесты , занимаясь только тем, что элемент управления
повысит удобство сопровождения из-за того, что вам не нужно поддерживать гигантский презентатор, содержащий объединение логики представления всех элементов управления
, что предотвратит избыточность в случае наличия одного и того же элемента управления на нескольких страницах
Увеличивает SRP с помощью элементов управления, фокусирующихся на их конкретной логике, в то время как страница выполняет роли, специфичные для контейнера:

Обычно упоминаются две проблемы, связанные с решением «предъявитель на элемент управления»:

Общий контекст является проблемой, когда из-за к тому факту, что все элементы управления просто показывают разные части одного контекста данных страницы,эта ситуация может выглядеть как проблемный вариант использования, приводящий к большому количеству избыточного кода для поиска данных в каждом из элементов управления. Это легко решается путем внедрения зависимостей, когда страница (или контроллер) выполняет одиночный поиск данных, а затем внедряет объект контекста данных в каждое из представителей \ представлений (обычно реализуя некоторый интерфейс, обеспечивающий это). В случае шаблона MV-VM (Silverlight, WPF) тот же эффект может быть достигнут посредством привязки данных, когда страница установит свой DataContext, который затем будет использоваться из самих представлений
Связь между представлениями на той же странице является второй проблема, которую легко решить, используя несколько подходов:
Элементы управления публикуют события , на которые подписывается страница, и затем выполняют прямые вызовы соответствующих методов в других элементах управления (страница является контейнером для всех элементов управления, что означает, что она осведомлена все их члены)
шаблон наблюдателя шаблон
шаблон агрегатора событий

В каждом из этих подходов элементы управления взаимодействуют друг с другом, не зная друг друга

18

ответ дан 30 November 2019 в 12:20

Другие вопросы по тегам:

c# design-patterns oop user-controls mvp

Похожие вопросы:

score 14 · Accepted Answer

Было бы разумнее сгруппировать код, связанный с одним объектом. Таким образом, в этом случае, если представления представляют собой конкретные группы связанного кода, докладчик также будет имитировать эти группировки. Чтобы иметь «глобального» презентатора для разных представлений, нужно сгруппировать несвязанный код в один объект. Это определенно раздуло бы интерфейс и для докладчика. Ознакомьтесь с принципом единоличной ответственности .

Теперь у вас может быть один класс Presenter Manager, который, возможно, предоставит вам доступ к каждому интерфейсу презентатора, , как утверждает принцип разделения интерфейса , с помощью любого наследования (есть глобальный конкретный презентатор, который реализует множество интерфейсов презентатора). .. какой вид нарушает единственную ответственность) или агрегацию (наличие отдельных презентаторов для каждого интерфейса и функций get ... таким образом, глобальный интерфейс будет функциями get) или их комбинацию (глобальный презентатор является своего рода адаптером).

Я думаю, что лучшим решением было бы просто иметь 30 разных докладчиков.