How to Model and ViewModel implementation for simple database

Question

I am trying my first steps with Microsoft ASP.Net MVC. I set up a simple database for being able to test all facets like Controllers, Views, Model, ViewModel, etc.

The case behind is to have simple Projects and Resources. Each Project can have multiple Resources. Each assigned Resource to a Project can have a Role (string).

My database model looks like this:

Projects
    Id <int>
    Name <string>
    CreatedAt <datetime>
    CreatedBy <string>

Resource
    Id <int>
    Name <string>
    CreatedAt <datetime>
    CreatedBy <string>

ProjectResources
    Id <int>
    ProjectId <int>
    ResourceId <int> 
    Role <string>
    CreatedAt <datetime>
    CreatedBy <string>

The first thing is to build the EntityClasses within the solution. I could have it like this:

public class Project
{
    public int Id { get; set; }
    public string  Name { get; set; }
    // IS THIS CORRECT? WHERE DO I HAVE TO PUT THE ROLE?
    public List<Resource> Resources { get; set; }
    public string  CreatedBy { get; }
    public datetime  CreatedAt { get; }
}

public class Resource
{
    public int Id { get; set; }
    public string  Name { get; set; }
    public string  CreatedBy { get; }
    public datetime  CreatedAt { get; }
}

This is the first part of the question. The second part is on ViewModels. What i have read is, that ViewModels should only contain those information which are rendered on a view. When i have 3 different views for 2 different purposes for example:

• Get list of projects
• Get single Project with assigned resources
• Save (edit/update & create new) project with assigned resources

So the question is: How could the ViewModel(s) look like? Do i need to have multiple ViewModels (from my understanding yes)? I have thought about it but dont know if this is ok (is there also any NamingConvention for ViewModels):

    public class ListOfProjectsViewModel
    {
        List<Project> projects { get; set; }
    }

But in this case where and how to put the joined Resources?

public class ProjectDetailViewModel
{
    Project project { get; set; }
    List<Resource> resources { get; set; }
}

In the class ProjectDetailViewModel i would have the list of resources for the dropdown but where to put the added/selected resources per project and the selected resources role?

Answer 1

If a project can have multiple resources, then Project will have a navigation property of a list of Resource and Resource will have a navigation property of a single Project. Of course this is making the assumption that one resource can be on a single project. Otherwise it will be a many to many relationship and you will have a List<T> navigation property on both sides.

Now the role: depending on your needs if a Resource can have multiple roles and role obviously has multiple resources, then again it is many to many so List<T> on both sides.

Also, you will need simple properties for (foreign keys) so they can be enforced by the database. Also, there will be cases when you just load a Resource without loading its Role (navigation property) and thus you need the RoleId.

As for the ViewModels:

Like I said, and I do not want to start this debate, there is no ViewModel in MVC. This is why the View has Model property. So whatever you pass to it is the Model. This is why there is a model folder.

Name your views as per operations such as Edit, Create, List (will display a list of x items) etc. Your Resource will need the following structure:

Views:

Resource - Edit - Create - List

Models:

Resource - EditModel or (ResourceEditModel) - CreateModel - ListModel

Your ListModel may have properties such as Total, PageNumber and your EditModel may have a list of Project for a dropdown selection and other items. That is all pretty normal. So you have the models for your views and then you have the models for your database and you may even have domain models.

And obviously you will have the controllers. Once you start using binding, error handling and validation on the client side, you will need ViewModels but at that point you are in the MVVM playground.