MVP:View 应该实现 Presenter 的接口还是反之亦然?
我正在使用 GWT
迈出第一步。 阅读后我有一个问题:
在第一个示例中 < code>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();
}
这种差异的想法是什么?
我应该选择哪个?
I am doing my first steps with GWT
.
I have a question after reading:
In the first example the Presenter
defines the interface for the 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();
}
}
And in the second one, the View
defines the interface for the 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();
}
What's the idea of this difference?
Which should I choose?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为您应该在问题中使用“定义”一词而不是“实现”,如果是这样的话,那么哪个类定义接口并不重要。
您可以通过定义来做一些不同的事情接口在它自己的文件中。归根结底,最重要的是实现 Presenter 接口的 Presenter 和实现 View 接口的 View。
I think you should have used the word 'defines' in your question instead of 'implements' and if thats the case then it does not matter which class defines the interface.
You could do something different by defining the interfaces in its own files. At the end of the day all that matters is the Presenter implementing the Presenter interface and the View implementing the View interface.
@deepak 这些都是合理的担忧。单词感染的是实现而不是定义。
让我解释一下。在第一个示例中,演示者遵守视图必须实现的约定,换句话说,驱动视图应该实现什么,这是经典的 MVP 方法。
在第二个例子中事情变得混乱。 Presenter 无法控制必须实现的视图。这不是 MVP,谷歌称其为 MVP。您无法使用这种方法通过 JRE/单元测试来测试视图。这并不会让事情变得更糟糕,尽管它不是 MVP,而且谷歌不应该称这个 MVP,或者他们必须解释为什么它是 MVP?
@Saket Bansal 分离接口不是正确的方法。随着应用程序的增长,这将导致代码难以维护。
在我看来,你可以采取任何一种方法,我记得谷歌说过,第一种方法适用于 adwords,第二种方法适用于 wave。
不管怎样,你也应该看看 GWTP 或来自 jboss 的 ERRAI 等框架
@deepak these are valid concerns . Word is infect implementation not definition .
Let me explain . In first example presenters hold the contract to what view must implement in other words drives what should be implemented by views a classical MVP approach .
Things get confusing in second example. Where Presenter has no control over what view must implement . This is not MVP and google is calling it as MVP . There is no way you can test the views with JRE /unit tests using this approach . That does not make it bad though just not MVP and google should not call this MVP or they must explain as to why is it an MVP ?
@Saket Bansal separating out interface is not correct approach . It will result in hard to maintain code as application grows .
In my opinion you can take either approach , I remember google saying some where first one worked for them for adwords and second for wave .
Any how you should also look at framworks like GWTP or ERRAI from jboss
在第二个教程中,代码更改为使用 Presenter 接口(在视图中定义)以适应 UiBinder 和 Java 泛型的使用。我认为 Presenter 接口已移至 View 接口,因为它们共享相同的通用 T。
In the second tutorial the code was changed to using a Presenter interface (defined in the view) to accommodate using UiBinders and Java generics. I think the Presenter interface was moved to the View interface as they both share the same generic T.