Develop Reference

MVVM Xamarin Forms Design

So I was looking at https://github.com/xamarin/Sport as an example I came across when googling something for my current project. It is similar to what Im working on because I use an azure backend as well.
I have a question about their mvvm layout. I thought that in mvvm the models were sort of POCOs and not supposed to implement INotifyPropertyChanged. Arent they acting as both a Model and a ViewModel in this case? Look at the Athlete model and the AthleteViewModel. The VM has a property for for Athlete and so the model is used as a VM as well.
In my project, if I had the same types, I would have an Athlete model, an AthleteViewModel and an AthletePageViewModel. Where the Athlete and AthleteVM would be automapped. The only reason to populate and or create the Athlete is to persist it to the service or local storage.
Is one way more "correct" than the other way? Or am I just doing it wrong and over complicating it? I almost don't want to continue with the way I'm doing it because I dont want to have a bunch of "extra" model files if I can just use some of my VMs as models.
Thanks.

There's no ultimate master set of strict rules that you need to follow in order to implement the MVVM design pattern. In fact, the guidelines are generally quite blurry.
From what I've seen, there are a couple of different methods of which a model may be exposed to the view. Here they are:
Method 1 - INotifyPropertyChanged in the Model
public class Car : INotifyPropertyChanged
{
private string _Model;
public string Model
{
get { return _Model; }
set
{
_Model = value;
NotifyOfPropertyChange();
}
}
...
}
public class CarViewModel
{
//The entire model is exposed to the view.
public Car Model { get; set; }
...
Method 2 - INotifyPropertyChanged in the View Model
public class CarViewModel
{
private Car _Car;
//The model property is exposed to the view, not the model itself.
public string CarModel
{
get { return _Car.Model; }
set
{
_Car.Model = value;
NotifyOfPropertyChange();
}
}
...
In terms of a preferred method, I would say method 2 is the better option. Why?
The Model object is not exposed to the view.
The View Model only exposes what the View needs.
Method 2 does have its downsides. Imagine if you needed to expose lots of model properties, or imagine if your model changes, it is certainly easier to simply implement INotifyPropertyChanged in the model and expose it to the view. Programmers are lazy by nature, therefore in order to save hassle, you'll see method 1 just as much as method 2.
But that isn't a bad thing.
Is one way more "correct" than the other way? Or am I just doing it wrong and over complicating it?
Remember, the MVVM design pattern is just a pattern. Neither options are correct, it's mostly down to the developers preference how they choose to approach the implementation of the pattern, as long as the main MVVM concepts are there, that's all that matters.

Best Practice Entity Framework Models vs ViewModels

From what I read, I understand that we should always pass a viewmodel to the view. However, sometimes this viewmodel is exactly or almost the same as the EF-model. Is it acceptable or is there any workaround to this problem (repetitive code) ?
For example, if I have this EF-Model :
class UserModel
{
string id {get;set}
string name {get;set}
string address {get;set}
string phone {get;set}
string website {get;set}
}
How should the viewmodel be ... like this :
class UserViewModel
{
string name {get;set}
string address {get;set}
string otherobject {get;set}
}
Or Like this :
class UserViewModel
{
UserModel user;
string otherobject {get;set}
}
With option #1, properties are repeated... and in another viewmodel they will be repeated again. And I will need to repeat all data annotations on each viewmodels. However, I send only the properties that I need.
With option #2, nothing is repeated, but I pass a lot of properties that I don't need.
The last option would be to mix option #1 and option #2 according to the needs... but I don't like this option because of the lack of a common standard. Sometimes the properties will be defined and datannoted in the viewmodels and sometimes in the EF-model.
I wish there is an option #4 that I don't see...?
Thank you.

The difference of those classes is how your application interacts with. Model and ViewModel has different audience.
Your Models should be interacting with your application, and sometimes many people prefer to use those models as entities in EF Code First. They are what we call Domain Objects.
On the other hand, ViewModels should be interacting with your Views. In your service layer, you populate your ViewModel with some data, and you can access them from your controllers.
However, sometimes this viewmodel is exactly or almost the same as the EF-model.
The keyword here is "sometimes". You are right, for a very simple application, you don't even need to think about ViewModels, where your models can simply be used in most cases. However, think about some cases for example where you want to display list of latest posts, latest comments, and let's say some related posts on a single view. What you are going to do? This is where the ViewModels come. You pass a specific ViewModel to your view, that contains all the necessary data, posts, comments, and related posts.
In most cases, you ViewModel should be build up from multiple Models, and sometimes, the porperties of a ViewModel are type of Models

I know it has been quite sometime since this question was asked. But, this may help someone who is looking for the answer.
Eventhough you have ViewModels which are almost same as models, it is recommended to create ViewModels with same code.
Possible reasons are
You may want to add validation to properties using Data Annotations.
It is not advised to have validation which are more specific to
screen in your models which are supposed to be reflections of your
DB structure.
Your ViewModels may change in future. It may not make sense now, but
there is always a possibility.
If you are worried about mapping code which looks obvious in most of the cases, you can make use of Automapper.
Cheers!

Is this correct way to implement MVVM?

I'm creating an application that enables a user to insert, update and delete data that has been entered and then shown in a data-grid (CRUD operations).
In my View Model, it contains properties which are bound to the xaml (Firstname for example). It also contains a navigation property as well as validation attributes.
[Required(ErrorMessage = "First Name is a required field")]
[RegularExpression(#"^[a-zA-Z''-'\s]{1,20}$", ErrorMessage = "First Name must contain no more then 20 characters and contain no digits.")]
public string FirstName
{
get { return _FirstName; }
set
{
if (_FirstName == value)
return;
_FirstName = value;
OnPropertyChanged("FirstName");
}
}
Furthermore, it contains commands for the xaml to execute, which creates an instance of the CRUD operation;
private void UpdateFormExecute()
{
var org = new OrganisationTypeDetail();
UpdateOrganisationTypeDetail(org);
}
And lastly, it contains the CRUD operations as well. Such as the Insert, Update and Delete.
Which leads me to my question. if I want to implement the correct MVVM way, is all this code too much for the view model to contain?
Should I use the model and create a collection within my View-model and bound that to my xaml? Would this be the correct way of doing it?
Should I use a Repository system for the CRUD operations? If so, how would I pass the data from the text fields through to the model to get updated?
Im new to WPF, MVVM and finding it hard to adapt without proper guidance.

I would say that this is a correct way to implement MVVM, but not the correct way to implement MVVM.
What I mean by this is that there is no one correct way to implement this pattern. if you have created a ViewModel that can be bound to your View, without having any extra logic within your View (i.e. code-behind) then you have captured the essence of MVVM.
Whether or not you add more patterns and structure to your code is entirely up to you. If this is a simple application, I would keep the patterns light. Go ahead and have your ViewModel talk directly with a repository. You current code looks just fine to me in that respect.
If this is a large application, you might want to add further layers, like a service layer, data access layer. You might want to think about dependency injection.
But don't just adopt a pattern, or add an extra layer just because you think you should. Dependency Injection sounds cool, but in many cases it is more hassle than it is worth!

For me it’s not the correct way, I think defining the properties like FirstName in view model is not good idea. view should contain model only and your view model should be wrap the model which should be bounded to XAML(if required).
Also model object creation should be completely independent of view model. View model should know only about unit operations on models and validations should be inside the model e.g in your case FirstName validations are in ViewModel means you are only limiting GUI to validate the FirstName property, but what if someone set it from other place.

In Asp.net MVC, is it advisable for viewmodels to derive from domain models?

(I am using ASP.Net MVC, but this seems like a more generic MVC question)
Say you have a domain model representing a person, and you have a view for editing a person. Included in the Person domain object is a State of Residence property, and in the view you want a dropdown that lists states.
Is there any reason not to create a view model that derives from the domain model and simply includes properties for the UI spiciness the view requires? If so, why would not not want to do this?
TIA

I would think that deriving a view model from a domain model would introduce coupling that MVC was intended to avoid; however, that said, do what makes the most sense for your application.
I prefer to have view models separate because doing so leaves me free to dramatically change the domain model and get improved compile time support for remapping my view model to the new domain model.

This is not a recommended practice and since you are asking you should not do it. The short answer is create a unique view model for each and every view you are going to render. Maintain a 1-1 view to viewmodel relationship and as you code you will see why.
The long answer can be found here amoung other places http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx
Thank you,
R

No, you don't really want to do this.
A big part of the reason to use ViewModels is because your domain entities tend to be big, spiky, complex and tied to persistence mechanisims. All leading for them to have strange, interesting or destructive behaviors when they encounter things such as the DefaultModelBinder.
By using much simpler ViewModel classes, you can avoid the bulk of these problems while also further decoupling your UI layer from your domain model.
Now, what you should do is provide easy means to generate a ViewModel from a Domain Entity or to updated a Domain Entity from a ViewModel.

I disagree with most of the advice here.
I think that your domain model should be clean and a viewmodel does what it has to.
If your view needs a person and the time in London i dont see the problem with doing this:
ExampleViewModel : Person {
Public DateTime LondonTime { get; set;}
}
Or
AnotherViewModel
{
Public Person SomeGuy { get; set;}
Public List<Kitty> Cats{ get; set;}
}
If your view needs a person and a list of kitties
This keeps your domain clean; the time of London is not related to a person however on your view you still need get the data. This is the whole point of a view model imho.

MVVM where to put Data Access Layer?

I am investigating WPF's MVVM design pattern. But am unsure where to put the Data Acess code?
In some examples I have looked at, data access is performed directly in the ViewModel. It seems odd to put something like linq to sql in the ViewModel? Other examples have a seperate project for Data Access, this seems more like it?
Is this there a general approach? I feel like I am missing something here!
Thanks

Here's how I've been organizing my MVVM w/ LINQ projects:
Model - I think of the Model as the state of the system. It provides an interface to the data, and it keeps track of system status. The Model does not know about the ViewModel or View--it just provides a public interface to its data and various events to let the consumers (usually ViewModels) know when the state has changed.
ViewModel - The ViewModel is in charge of organizing or structuring all the data needed by the View, keeping track of the status of the view (such as the currently selected row of a data grid), and responding to actions on the view (such as button pushes). It knows what the view needs, but it doesn't actually know about the view.
View - The View is the actual look and feel of the UI. It contains all the built-in and custom controls, how they arranged, and how they are styled. It knows about the ViewModel, but only for the purpose of binding to its properties.
Gateway - This is the part that directly addresses your question. The Gateway (which is basically my way of saying "DataAccessLayer") is its own separate layer. It contains all the code (including LINQ queries) to CRUD or select, insert, update, and delete data from/to your data source (database, XML file, etc.). It also provides a public interface to the Model, allowing the Model to focus on maintaining system state without having to concern itself with the details (i.e., the queries) needed to update the data source.
DataAccess Classes - In C#, these are very simple classes that model your elemental data objects. When you select something using a LINQ query, you will usually create an IEnumerable<T> or List<T> where T is one of your data objects. An example of a data object would be:
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
The big advantage of a design like this is that it really separates your concerns. Everything has a specialized job, and it's (usually) pretty easy to know what kind of thing goes where.
The disadvantage is that it may be overkill for small projects. You end up creating a lot of infrastructure for public interfaces that basically pass a single wish through several layers. So, you might end up with a scenario like this: [user clicks Submit, ViewModel tells Model to AddNewPerson, Model tells Gateway to InsertPerson] instead of a scenario like this [user clicks Submit, ViewModel adds new record to the database directly].
Hope that helps.

I would add another layer, essentially what you want is a data factory. You want to create a set of classes that will CRUD to the database for you and return clean POCO objects to the ViewModel.
A good example to look at would the Nerd Dinner book. It covers MVC not MVVM but the patterns are very similar and the way they access data in that solution would be good starting point.
Hope this helps.

Data access should not be in the view model, as this is supposed to be a view specific (possibly simplified) representation of the domain model.
Use a mapper of some sort to map your view model (the VM in MVVM) to your model (the first M). New objects in your model can be created using the factory pattern. Once created, you can store them in a database using the repository pattern. The repositories would then represent your data access layer. In your repository you could use an O/R mapper like NHibernate or Entity Framework.
EDIT:
I see that GraemeF suggests putting the data access code in the model. This is a NOT a good approach, as this would force you to update your domain model if you were to move from e.g. SQL Server to Oracle or XML files. The domain objects should not have to worry about how they are persisted. The repository pattern isolates the domain from its persistence.

MVVM stands for Model, View, and ViewModel. The piece you are missing is the Model, which is where your data access code lives.
The ViewModel takes the Model and presents it to the View for display, so typically you would have something like this:
class PersonModel : IPerson
{
// data access stuff goes in here
public string Name { get; set; }
}
class PersonViewModel
{
IPerson _person;
public PersonViewModel(IPerson person)
{
_person = person;
}
public Name
{
get { return _person.Name; }
set { _person.Name = value; }
}
}
The PersonView would then bind to the properties of the PersonViewModel rather than directly to the model itself. In many cases you might already have a data access layer that knows nothing about MVVM (and nor should it) but you can still build ViewModels to present it to the view.

Your ViewModel should be a thin layer that just services the view. My rule of thumb: if it has to do with the presentation of the UI, then it belongs in the ViewModel, otherwise it should be in the Model.

The WPF Application Framework (WAF) contains a sample application that shows how the Model-View-ViewModel (MVVM) pattern might be used in combination with the Entity Framework.