0

Implementing the Observer pattern in MVC could mean making Model Observable and View Observers. However, this also means that there will be direct communication between views and models without the involvement of Controller? Does that violate MVC spirit? It seems to.

The second option could be making Controller the observer.

Which option is more "authentic"? Or do we have both flavors available in the wild?

Improve this question
1
  • 1
    Why do want to implement the observer pattern in MVC? What problem are you trying to solve?
    – David Arno
    Commented Oct 19, 2021 at 17:49

2 Answers 2

Reset to default
4

Which option is more "authentic"? Or do we have both flavors available in the wild?

If you have at least 3 components dedicated to model, view, and controller, respectively, you're authentically MVC. How those components communicate isn't standardized. Why? Because MVC is our oldest design pattern. It was created before we had any idea how communication should happen between those components. Therefore the focus of the pattern is about separating these concerns.

This is why if you do a google image search for Model View Controller you don't see consistency in the arrows of the diagrams. You see stuff like this:

enter image description here

So if you've had trouble figuring out the "authentic" way to wire up the 3 components you're in good company. The MVC pattern simply doesn't tell us how to do this.

But, there are other patterns that do:

enter image description here

Those patterns talk about how to communicate. But every one can be thought of as following MVC. So if you just tell me you're using MVC please don't think you've told me how your components communicate. I'd have no idea. That's not part of the pattern.

Now that said, there is something called the principle of least astonishment. Your first option doesn't make me bat an eye. But your second? Well, if you told me your Controller was observing the Model my reaction would be, "Huh, ok, why?"

Improve this answer
0

Classic MVC leads to a circular data flow:

  +----- VIEW <----+
  v                |
USER              MODEL
  |                ^
  +--> CONTROLLER -+

The user manipulates the Model through the Controller. The current state of the Model is shown to the user via a View.

It is completely normal to use the Observer Pattern to keep the View in sync with the Model. This combination of MVC + Observer is also discussed in the Gang of Four Design Patterns book.

But there are slightly different patterns that share the MVC name. In the Web MVC pattern, the (server-side) controller mediates between the user and the Model. The View is part of the response returned to the user via the Controller. The Model is typically not a persistent object graph that could be observable, but some business logic that is “hydrated” as needed with data from a database. The web's request–ŕesponse model is not a good match for automatic updates as with the Observer pattern, though it can be modelled using WebSockets. Such updates wouldn't be anti-MVC, but of course the architecture must consider the data flows through both normal HTTP requests and through WebSockets.

Improve this answer
3
  • "As for third parties, that may figure into the equation somewhere, but not much. Usually third parties are abstracted away and stubbed.". I am coming to the conclusion that the GoF book is a collection of bad designs and we'd do the world a favour if we gather them all up and burned them. The observer pattern is just events. There is no sensible use-case for events in an MVC implementation. But maybe we talk of different MVCs as I disagree with your diagram of it. The model responds to the controller. The controller constructs a view and sends it back to the user.
    – David Arno
    Commented Oct 19, 2021 at 19:19
  • @DavidArno I have no idea what you're quoting there. It's not my answer and not the GoF book. In any case there has been much valid criticism of design patterns, in particular when used in a prescriptive fashion. But no one can read the GoF book and reasonably come to the conclusion that its description of things that seem to work (= “patterns”) are bad.
    – amon
    Commented Oct 19, 2021 at 19:48
  • @DavidArno My answer discusses both the original Smalltalk-MVC and the more well-known Web-MVC variants of the architecture. In the original MVC, Observer-like events and data binding is basically the core feature. It's the grand-daddy of stuff like React. Fowler has an article tracing the history of early GUI architectures like MVC. Web-MVC is an effectively unrelated pattern that is more like GUI-MVP where the view becomes passive, and your criticism applies in the web context.
    – amon
    Commented Oct 19, 2021 at 19:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.