Click here to Skip to main content
15,899,825 members
Search within:


From where does Model get data in MVVM?
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Silverlight4
MVVM
I am currently studying MVVM pattern. I am clear with the concept that Model contains classes, View is just the visual representation of data and ViewModel is the layer that connects Model and View and carry out all manipulations.

But i m still not clear with the fact that from where does Model get data? Since it contains only properties. So even if we use WCF to fill in data, still the question remains:

Is any intermediate class required to fill in data in Model or this work is also carried out via ViewModel?

Model gives data to ViewModel, which in turn gives formatted data to View and View just represents the data. But from where does Model get the data?
Posted
Add a Solution

2 solutions

"Model" is itself data. More example, Model includes classes which describe the data, instance of those classes during runtime (some object graph) is truly the data. I think you should be more accurate in distinction of data. When you say "get data", and, say, "population", you might mean persistent form of this data, database of some file(s) in some non-volatile storage. This detail goes beyond level of detail described by the pattern and is a part of Model, I would say, pretty marginal. Separate classes or not, depends on your own code design. In some complex situations, you may need to have a whole big abstraction level between your application and database, it could be even a separate tier. Or it could be a simple call to a serializer method. The MVVM pattern is abstracted from this detail, which is relatively trivial. The pattern is focused on like cycle and collaboration between UI, data and application state, as well as other patterns of this level, like MVC and MVP.

I think the roles or all parts of this architectural patterns are explained clearly enough here: http://en.wikipedia.org/wiki/Model_View_ViewModel[^].

You should understand that patterns of this level is not very fundamental to computer science. It rather reflect cultural, social and commercial situation (be some natural historical reasons though), where we don't have any serious unification in the UI design and tools. UI tends to change more often then most people would like and UI frameworks are wildly incompatible between different platforms. All other parts of software are much more portable compared to UI parts. Such situation requires UI to be strongly isolated from other application aspects. All the pattern we discuss help developers to isolate big part of works from UI, make development smoother and, most importantly, to preserve heavy investment in software when people have to change the UI part again.

—SA
 
Share this answer
 
Posted
Comments
Member 9472447 28-Nov-13 5:09am    
I am understanding your point but still the confusion remains.. Even if i have to fill up data manually, then also should it be done in Model itself or in ViewModel or any intermediate class??
Sergey Alexandrovich Kryukov 28-Nov-13 10:40am    
Probably you only have a little confusion related to understanding what is Model as a category. Amazingly, most overviews of those types of architectural patters don't give them a name. They just say: there are "Model, View, and ViewModel" (Model, View and Controller). They don't say "three classes", or "three layers", not common meta-name of a concept. In one place I found "components", somewhere else, "types of components". All right, there are certainly not layers, because there is no "lower-upper" relationships between then (like dependencies), and they don't have to be classes. The architectural pattern is simply abstracted from those classes, considering them implementation detail (but not a particular framework implementing the pattern). In all cases, adding an intermediate class is up to you. If you fill data in Model, you do it in Model part (you see, not I say "part" as a meta-name :-), because this is just the closest one. You full data in the Model (I have no idea why do you call it "manual", it can be automated to different degrees of universality), you do it my some code classified as part of the Model; and it's up to you do decide if you create just one method for it, a separate "intermediate class" or whole layer, but whatever you create could be considered as a part of Model.
Does it seem more logical now?
—SA
Put simply, MVVM does not determine from where your model classes get their data - MVVM is just a pattern used for development.

Your model classes could be plain old objects that you populate programatically (say via a datareader from a database, or from loading a CSV file from disk - MVVM doesn't dictate this.)

Your model classes could be Entity Framework classes, LLBLGen Entity classes, or DataTable classes - indeed any combination!

I would generally use some sort of service to present a Model object to the ViewModel - so the Vm knows about the service, and knows about the Model class, but has no concept of how the MOdel was constructed.

The service can then create the Model however it wishes - using any of the methods above - and return the object to the VM.
 
Share this answer
 
Posted
Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month
Related Questions
Mvvm datagrid not updating.
MVVM with multiple view models
Silverlight LisBox Data Binding MVVM
How to fetch database data to combobox in silverlight MVVM model
Entity Data Model is faster?
mvvm and model-dependencies
Wpf: combobox, SQL server and MVVM
Implementation of model in MVVM
Using the MVVM pattern: what should raise the propertychanged event, if the a property of an instance of a (Data)Model class is changed?
How to structure viewmodel / model classes and where to put calculation/total properties

Advertise
Privacy
Cookies
Terms of Use
Last Updated 1 Dec 2013
Layout: fixed | fluid
Copyright © CodeProject, 1999-2024
All Rights Reserved.

Web01 2.8:2024-05-14:1

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900