0

Basically there is two options as I know.

The first is view expose notifications events which a presenter should be subscribed to. When user clicks on some button on the view, view just triggers some event, notifies that something is changed.

The second is just use an observer pattern and let the presenter interfere some contract. Let it be an interface with methods like events I told you above. An presenter-observer should be attached to the view.

As Jeremy Miller in his legendary "Build your own CAB series" blog posts said, it's better for him to use the second option.

What's your opinion on this topic? How do you tie presenter and view in your projects? What's advantages or disadvantages for every options?

Let make some poll here. I think it would be useful. Thanks in advance!

In order to respond to Peter Ritchie's answer.

My issue is that my inexperience and I should rely on somebody's opinion to make a decision and choose a way that seems right to me.

The drawback with interfaces is that you have specific coupling. The view is coupled to an interface and something has to implement that interface

But on the other hand, is not events serves like a some contract (like an interface do)? It tied presenter to the view as it should react over that events.

kseen
  • 359
  • 8
  • 56
  • 104
  • events are a looser contract. You subscriber to an event with a delegate; this could be a public method, a private method, an anonymous method, etc. With an interface, it has to implement that interface as public methods. – Peter Ritchie May 12 '12 at 15:05

1 Answers1

2

Observer can be a bit tedious. If you have several controls that produce events or several events, then you have to wire them up one at a time. Whereas if you use an interface, it's all in one place and you get type-safety and compile errors if you forget to implement a specific member of the interface. The drawback with interfaces is that you have specific coupling. The view is coupled to an interface and something has to implement that interface. you can use interface segregation to limit the interface coupling to one specific class; but, that adds a certain level of complexity.

There's no one right answer for this; is there some criteria you can offer to help with your decision?

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98
  • @Peter Ritchie , can you throw some light on how should one communicate from `model` to `presenter` so that `presenter` could perform some action on `view`. for eg, say, database read is done in `model` then, how should `model` tell to `presenter` that it has read the data and pass back the data to `presenter` so that `presenter` could update `view` – eRaisedToX May 25 '17 at 06:15
  • 1
    @eRaisedToX It's vital that model should be as loosely coupled to the presenter as possible (you theoretically can't entirely "decouple" something from something that uses it). That's done with typical abstraction and encapsulation techniques. As I mentioned above, one way is to effectively use Dependency Inversion and depend on interfaces (abstractions) instead of directly upon a presenter or a particular presenter. But, that means the presenter needs to have an instance of that interface in order to invoke it. Another type of abstraction is to broker communication between... – Peter Ritchie May 25 '17 at 14:39
  • 1
    ...the model and the presenter via a proxy of some sort. Often we see that implemented with message queues but that doesn't mean using "middleware". For example, typically UI frameworks communicate from the view to the applications via messages--which is a way of decoupling the UI framework from any particular action--without using middleware. I'm quite fond of that type of decoupling, I find it very flexible. So a model could communicate to other things by putting messages on a queue (which could simple be an instance of ConcurrentQueue). – Peter Ritchie May 25 '17 at 14:43
  • Thanks a lot for your valuable comment..! It would really help . – eRaisedToX May 26 '17 at 04:59