You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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 CustomerForm. In case of events the integration is more vague and you would need to trace down the flow of events to reason about the interaction of the view and presentation layers.
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: