I am passing Menu items to View from ViewModel. My menu definition is a model with properties title, image, hasChildren and isEnabled. But this model is meant for UI unlike business domain models like Person, ContactDetail, Transaction, etc.
So, when i see this menu model sitting along with business domain models i felt like polluted. Is there a right place to put these kind of UI specific models?
Thanks.
I am passing Menu items to View from ViewModel.
I think you're really close but missing the mark on MVVM slightly. I'm not sure what language/framework you're applying this in, so I'll answer generically. I know .NET is typical when you hear MVVM but the pattern can be applied anywhere.
Let me start by correcting your initial statement:
I am passing menu ViewModels to the View.
You are absolutely right to consider this view-specific model of a menu item to be distinct from your business domain models. Make sure you're calling them ViewModels as opposed to Models.
As for where you put them, you have a few options. You could put them in the same folder as your Models but name them distinctly as ViewModels. You can also give them their own directory, so your Models and ViewModels are not intermingled. This is all a matter of code organization, and either of these options is valid. Perhaps the latter (separate folders) is slightly cleaner.
Note, I didn't say where the ViewModels are passed from. A better way to think about how Models, ViewModels, and Views pass each other around is to describe where each are consumed. This also depends on your framework how things are passed around (or declared), but here's the basic idea.
The View can reference a ViewModel that has the data it needs to bind. The View has no concept of a business model, or at least, it doesn't work with one directly.
The ViewModel can reference a Model. It might get data right off of it, or even invoke the Model's methods to derive data. It might also have some logic of its own, logic that is view-specific as opposed to domain-specific. It is often a subset of the original Model, with the added responsibility of view-specific concerns like formatting dates and numbers. The ViewModel doesn't need to know about the View, and it could even be consumed by multiple Views.
The Model has no concept of ViewModels or Views. It is your pure business model/domain object. It might handle data calculations or derivations based on business logic. It should not care about presentations concerns like formatting.
For further reading, I suggest the section titled The Evolution of Model-View-ViewModel in this article, specifically, the last two paragraphs of that section.
The MVC model is the model of the highest level. The UI, by itself can be considered as another SW, one abstraction level below. But it itself can have its own entities (the persistent UI configuration, set by user) and its model, mentioned by you.
Here we are coming to a contradiction, of course. Only the components of Controller layer should speak to each other, according to the model... But these control functions have nothing in common! But that is a contradiction only if we'll take the MVC conception literally. The pure three "layers" can serve only for the most primitive architectures, where there are only two poles - data and user, and we define layers along the tie between them. A real application has many such poles. And any tie between one pole and another one can and should be sliced into layers.
The definition of these poles is up to you, I don't know the complexity of your work, but as you obviously want the dynamic interface, there will be minimally tree poles - Business data, Interface data and user. There are two ties - User-BuD and User-InD. And you'll have two different controllers - for each of them. You can also have two interfaces - the normal interface and the inferface for interface settings. These latter two will have common elements. Funny enough, on this abstraction level the controllers won't cooperate with each other and interfaces - will do.
BTW, even this architecture is very simplified, for you need also the administration data? maybe license data? And you need to serve them, too.
You are working on the View within your Model/View/Controller.
The model is the business of your application. The View displays visual elements (In this case a menu) and the Controller handles dynamic user interaction (Which keystrokes do what, which pointer selections ask the view to be active etc.) The View and Controller are nearly always very closely tied. Of course in the HTML world we hardly think about the controller aspect of the UI but in writing native applications it use to be much more hands on than it is now.
Most classes within M, V and C have instance variables. There is no need to be embarrassed that your menu (ie view) has state, it is still perfectly valid to think of it as part of the View.
I also get the idea that you could subclass (Or not) many different designs of menu within your view but you don't need to think of the attributes as being the model. They are the state needed to render the view and the detail belongs within the view.
In .net mvc there is a concept called a view model, which is a class that is meant to take 1-n domain models and implement them for a specific view. It had become a best practice for more complex applications to include a view model for every view. You also find a similar practice in django with modelforms.
The mv* pattern doesn't mean you can't write classes to integrate your domain models. But those classes should not be in your domain model structure. The pattern is means of implementing SOC and having mixing domain and ui models breaks breaks that separation.
I would implement an additional ui class layer meant to translate domain models into different interfaces and have views talk with this layer.
