MVP: Должен ли View реализовывать интерфейс Presenter или наоборот?

Я делаю свои первые шаги с GWT. У меня вопрос после прочтения:

В первом примере Presenter определяет интерфейс для View.

public class ContactsPresenter implements Presenter {
  ...
  public interface Display extends HasValue<List<String>> {
    HasClickHandlers getAddButton();
    HasClickHandlers getDeleteButton();
    HasClickHandlers getList();
    void setData(List<String> data);
    int getClickedRow(ClickEvent event);
    List<Integer> getSelectedRows();
    Widget asWidget();
  }
}

А во втором View определяет интерфейс для Presenter.

public interface ContactsView<T> {

  public interface Presenter<T> {
    void onAddButtonClicked();
    void onDeleteButtonClicked();
    void onItemClicked(T clickedItem);
    void onItemSelected(T selectedItem);
  }

  void setPresenter(Presenter<T> presenter);
  void setColumnDefinitions(List<ColumnDefinition<T>> columnDefinitions);
  void setRowData(List<T> rowData);
  Widget asWidget();
}

В чем смысл этой разницы?

какой я должен выбрать?


java mvp gwt gwt-mvp
person Macarse    schedule 22.07.2010    source источник
comment
Докладчик должен иметь возможность изменять представление. Итак, ведущему просто нужно поддерживать ссылку на свои взгляды. Я не понимаю, что получится, если представление и ведущий будут реализовывать друг друга.   -  person Abhijeet Kashnia    schedule 22.07.2010
comment
@Abhijeet Kashnia: Это два разных примера. Проверьте ссылки, они делают то же самое, но реализованы по-разному.   -  person Macarse    schedule 22.07.2010
comment
Даже в управлении историей с Activity и Places и MVP у нас есть Activity, реализующий интерфейс просмотра! Как это MVP?   -  person Nitish Upreti    schedule 21.06.2011

Ответы (3)


arrow_upward
2
arrow_downward

Я думаю, вы должны были использовать слово «определяет» в своем вопросе вместо «реализует», и если это так, то не имеет значения, какой класс определяет интерфейс.

Вы можете сделать что-то другое, определив интерфейсы в своих собственных файлах. В конце концов, все, что имеет значение, — это Presenter, реализующий интерфейс Presenter, и View, реализующий интерфейс View.

person prav    schedule 22.07.2010

arrow_upward
2
arrow_downward

@deepak это обоснованные опасения. Word заражает реализацию, а не определение.

Позволь мне объяснить . В первом примере презентеры держат контракт на то, какое представление должно быть реализовано, другими словами, управляет тем, что должно быть реализовано представлениями в классическом подходе MVP.

Все становится запутанным во втором примере. Где Presenter не имеет контроля над тем, какое представление должно быть реализовано. Это не MVP, и Google называет это MVP. Используя этот подход, вы не сможете протестировать представления с помощью JRE/модульных тестов. Это не делает его плохим, хотя просто не MVP, и Google не должен называть это MVP или они должны объяснить, почему это MVP?

@Saket Bansal, отделяющий интерфейс, - неправильный подход. Это приведет к сложности поддержки кода по мере роста приложения.

По моему мнению, вы можете выбрать любой из этих подходов, я помню, как Google говорил о том, что первый подход работал у них для adwords, а второй — для волны.

В любом случае вам также следует взглянуть на фреймворки, такие как GWTP или ERRAI от jboss.

person Shahzeb    schedule 14.09.2010

arrow_upward
0
arrow_downward

Во втором учебнике код был изменен на использование интерфейса Presenter (определенного в представлении), чтобы приспособиться к использованию UiBinders и дженериков Java. Я думаю, что интерфейс Presenter был перемещен в интерфейс View, поскольку они оба используют один и тот же общий T.

person Martin    schedule 22.07.2010