-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should the View rather not know about Presenter? #4
Comments
Good point, thanks for bringing this up! Sure, using events is one excellent way of doing it. However, there's a big difference between tight coupling and tight cohesion (or integration), where the former is undesirable and the latter desirable. When the view invokes the presenter directly, then the role and function of the presenter is clear and explicit at a glance, like it is for example in So, in my opinion there is a benefit of tight cohesion at the expense of a little coupling when the view knows about the presenter. You have to pick your wins and losses, every option comes with its pluses and minuses. |
First of all, many thanks Mart for putting this repo together, very useful.
The comment I have, should the View rather not know anything about Presenter? Here you have a reference to
CustomerPresenter
insideICustomerView
:winforms-mvp/WinFormsMVP/WinFormsMVP/View/ICustomerView.cs
Line 17 in 7470a9e
I'd expect to have no tight coupling here. Rather, some sort of event sources or observables that the Presenter would be subscribing to. Something similar to what Mark Heath is doing in his related article:
The text was updated successfully, but these errors were encountered: