Is the M in MVC different than in MVVM?

Question

First, I'd like to apologize for adding to the myriad of questions on this topic. I understand the basic difference between MVVM and MVC. What I don't understand is the exact definition for the M.

In my understanding of MVC (which is consistent with what's out on wikipedia), the Model encapsulates the state (and possibly business logic) of the application. It lets the View know when something's changed. It might be implemented as a class with methods that allow data to be stored or retrieved. It might have an interface that allows the View to listen to changes in data.

I've read similar descriptions of the Model in MVVM. However, frequently, I find people referring to the Model as the classes that represent the things you're modeling in your business domain. In his article, John Papa refers to the Model as, “A class that represents data points describing a specific entity. For example, a Customer class with properties such as CompanyName and CustomerId”. He goes on to explain that, “I have a class that is in charge of hitting a web service to go and get my data and fill my Model for my ViewModel”.

Normally, I'd call the class that models some domain concept a domain class. I'd agree that the Model references those classes, but it doesn't own them. I'd agree with John that encapsulating the job of filling these classes with data obtained from a service is a good idea. He seems to imply that this is the job of the ViewModel, or some other piece. I thought that this was a key job of the Model. Sure, have a class (or whatever) to do it, but that class is part of the model itself.

Is the M in MVC/MVVM the class that model's some domain concept? Or is it the thing that encapsulates the application's data?

I'd love for someone to tell me I'm not crazy and that somewhere along the line, people in the MS camp have fundamentally changed the idea of what Model means in these patterns. Er, maybe I'm in the wrong place for that though:)

Answer 1

They are the same; the M refers to the domain classes, and also the service layer (if you have one) encapsulating the business logic.

The general principle is this: you want a fat model, a view that is as thin as possible, and a controller or viewmodel that is also thin, but fat enough to make the view as thin as possible.

Answer 2

There's really no absolute in this, it's always open to interpretation. Patterns like MVC and MVVM really exist to define a vocabulary to describe how a problem has or might be solved - the pattern is not an end in itself.

So the key part is to understand how a particular author is using it in the current problem domain. And in some cases, the model can be applied differently within the same application.

For example - the model can be a pure 1-1 representation of the domain object. So the model effectively is the domain object. This model can also be passed through to the view, so it is also the view model. So in this case, domain = model = view model.

In other parts, the model may require additional information for it to be utilised in an application - say the customer requires the user to select a state. In this case - you could just type the state in... but a better experience would be to provide a list of selectable states. These selectable states really don't define the domain per se - even though they are domain constraints, but they do provide information to the view. In this case, I would add the select list to the model. As it now contains information for the view, I consider it a view model.

It also works the other way - if you are only displaying the first and last name of a customer, then you may want to pull all the other information out of the domain to provide only what is needed. Once again, you are restricting the domain model for the purpose of the view. So in this case, again, we have a view model.

So the way I see it - the M in MVC refers to any type of model - but the MVC patter refers to a pattern of presentation, navigation, actions and controls. The MVVM (to me) provides a bit greater detail to describe the situation where you've created a view model.

The application is based on MVC - it has controllers, actions, views... and some of the controller/view interaction is based on MVVM whilst others may be passing the entire model.

I don't think MS are particularly muddying the waters either - the pattern has been used way back in C++ / MFC classes when it was called doc-view. (Showing my age now)

Kind of rambling answer - hope it helps.