Is the Model-View-Controller pattern very strictly defined, to it’s design details? Or is it a term, like many others, with lots of different interpretations and versions (that all fit the definition)?
I have come across many ‘versions’ and interpretations of the MVC term. For example: Some versions state that using the Observer pattern, the View registers as an observer to the Model. Through this the View gets updates from the Model when it changes, and can update itself. Other versions claim that the View must never interact with the Model in any way.
The first version is from the Head First Design Patterns book. The second version I read here on Programmers. Two contradicting interpretation of the specific design-details of the MVC. And there are more examples.
My question is: Is the definition for the MVC pattern one of these terms that are interpreted in a variety of ways, which are all acceptable?
I am not talking about the higher-view definition of the pattern. This has a pretty clear definition.
I am talking about more specific details of design. Examples: Should Observer be used to update the View about changes of the Model? Should orders to the View to update be passed to it only through the Controller, or may be told to it by the Model directly? Things like these.
Do MVC versions vary in these details, but all still fit the MVC definition? Or is it simply that there are lots of ‘wrong’ MVC implementations?
2
I’m not sure what to tell you based on what you’re asking.
Is the definition for the MVC pattern one of these terms that are interpreted in a variety of ways, which are all acceptable?
Well, yes. I mean, every concept has a history, right? So back in the late 80s, Smalltalk developers coined the term “MVC”, and it had many of the features you expect — a model holding data state, a view responsible for presentation and UI handling, and a controller that coordinates the two.
However, when it gets into details of implementation, you’re going to find a lot of variety. Now, you’ll hear die-hard GoF guys say that only the GoF definition is properly called “MVC”, but I personally don’t agree, because I’ve seen things that look like MVC with many variations (who owns what, who’s allowed to talk to whom, etc.)
In fact, I would actually go further and say that “MVC” is a lot like the triangle is to building architecture. It’s a shape (or in this case a set of three relationships) that provide an important characteristic — separation of concerns.
I’ve seen apps built such that each of the MVC components THEMSELVES have MVC-like classes inside. (For example, you’ll have a meta-view, meta-controller, and meta-model, and maybe the meta-view has a model for how it accesses its setup data, a view for actually rendering the controls, and a controller that is the external interface to the meta components).
So I view MVC as more of a building block than a limited thing with only one valid implementation.
I think your question is not answerable at all, and you will ended up getting all again different opinion-based answers. You can’t basically compare a definition that you’re not actually sharing it with us — I might have a different understanding of MVC, with all the known/unknown implementations.
People usually do Experiment with what they have. That could simply lead to thousands of either creative or ill-designed applications, however it’s necessary for improvement.
Also people have different Understanding of same things. That’s why we appreciate Team Work. A design pattern also is a work-on-progress like every other thing in this world. You can’t directly jump from MVC to better-MVC in a day. What you see is the natural way of Learning and Creating.
Also most of the time you have to mix design-patterns to get what you want. It might be possible to implement only MVC for smaller applications, but there are many cases that you need to mix your MVC — or whatever else, with other design-patterns. That might force you to change some aspects of your MVC. That might confuse people, or they might even hate you, but that’s the way we learn and live: Trial and Error.
Perhaps a simple example is in order.
Most MVC implementations have a feature called “convention over configuration.” What that means is that some configuration values can be “assumed.” For instance, consider this controller method in ASP.NET MVC:
public View Index()
{
return View();
}
This bit of code (absent several additional details for simplicity) returns the “Index” view, because the controller assumes that you are returning the view with the same name as that of the controller method.
But what if I specified the view explicitly?
public View Index()
{
return View("Index");
}
It still returns the “Index” view, but this time I have stated my intention explicitly. I am no longer using “convention over configuration,” however.
Does this make it any less “MVC”? Of course not.
Naturally, there are varying degrees of compliance, and there may come a time when you have departed from the “spirit and intent” of MVC to a degree in which it is no longer plausible to still call it MVC.
Winforms could never be called MVC, although there are ways to write it (and libraries to support it) which can emulate Model-View-Presenter.