Comment by catpolice | Hacker News Reader

Comment by catpolice | Hacker News Reader

Parent Full thread

I tend to use the "model" and "view" concepts a lot when discussing architecture, but in my experience it's almost always a mistake to try and reference any specific MV* pattern for explanatory purposes - it does not have the effect of making the discussion clearer.

The issue is that there isn't actually a consensus about what constitutes the definitional features of these patterns, especially when it comes to how the concepts involved actually translate into code. For any sufficiently notable discussion of an MV* pattern, you're going to find an argument in the comments about whether the author actually understands the pattern or is talking about something else, and typically the commenters will be talking past one another.

Note that I'm NOT claiming that there's anything wrong with your favorite explanation of MV* - it may be perfectly well defined and concrete and useful once you understand it. The issue is a feature of the community: lots of other people have a different (and possibly worse) understanding of what MV* means, so when you start talking about it and your understandings don't align, confusion arises. Getting those understandings back in alignment is more trouble than the acronyms are worth.

I've seen enough conversations about concrete development issues suddenly turn into disagreements about the meaning of words to realize that nothing useful is conveyed by mentioning MV* and assuming anyone knows what you're talking about - it's better to spell out exactly what you mean in reference to the code you're actually talking about, even if you have to use more words.

I think there is an essential core of an idea in "MVC" which sustains across all of its interpretations/implementations.

The core idea is: you want to keep a firm separation between UI code (view) and object-oriented business logic (model).

Other objects will need to reuse your model as your application grows; UI code will clutter that reuse. For example, your business logic should return an array of Customers, not an array of UI labels. The business logic shouldn't directly refer to UI code at all.

In addition, you'll probably want to reuse some of your UI code in multiple contexts. A fancy resizable scrollable table shouldn't directly refer to Customers, because you might also want to use it to display a list of Purchases.

But if the business logic shouldn't directly refer to UI code, and UI code shouldn't directly refer to business logic, then you'll need some code to bridge the gap. That's the controller.

But this idea still leaves a great deal open to interpretation. How much work should the controller do, vs. pushing that work to the model or the view code? What's "business logic" as opposed to "view logic"? Should the controller code be a single object? Is your view logic complicated enough (and reusable enough) to justify separating it out into another object (a "view model")? If you never write any reusable view code, do you even have/need MVC? All of these questions are unresolved by "MVC."

But I doubt that this core idea is what the original MVC idea had in mind.

I believe the original idea was that the MV and C are separated but coupled. So all views that bind to a model will update at the same time when a controller calls a change in the model.

On the web this concept is strange. I think this is why there are so many different MVC concepts.

We should simply stop referring to MVC as a "pattern", and call it what it is instead, a high level, abstract, general idea on how to structure an application. There isn't a right or wrong interpretation or implementation, just different applications of the same idea.

Go to, let us go down, and there confound their pattern language, that they may not understand one another's speech.

I tend to think of MV* as a misnomer, because people generally seem to understand now that "Model" constitutes the business logic and any associated business data (be it a database or document).

But every single environment is going to have a different circle drawn around what a View is - what is provided, what you are expected to build yourself, and how to interface the two. For instance, the V and C are partially a separation assuming it is appropriate to have a decoupling of input and output.

The most important concept is that your model should be separate from all that. If you want to show the model in some new clever way, that should be via some View-ish functionalities manipulating data gained from the model. If you want some cool new behavior or functionality though, you should put that business logic entirely within the model. Then, you can properly control the boundary between the two sides - if all you do is add new methods or expose new data without changing behavior, you know that everything outside the model will still work without change. Start changing existing behavior, and your UI pieces will likely need to change to accommodate that.

Reply on news.ycombinator.com