C# – Is it Right to Have Dependencies to ViewModel from Data Access Layer and View Layer?

asp.netcdependenciesdesign-patternsmvvm

Context

In my application I use the MVVM pattern. I'll have a ViewModel that can contains information of a student. This viewmodel is used to communicatie between my view and model. I use ASP.net core MVC whit vue.js.

My project contains out of the following elements:

Views (UI)
Controller API (responsible for responding to requests from the view)
Models (logic)
ViewModels(Containing information for the views)
Repository (repository pattern for communicating whit database)

Senario

When the end user creates for example a student it will fill in some data and and press button to safe the student. Now the information will be send to the server whit a ajax call. The Controller API now catches the HTTP request and cast it to the view model.

Controller API

    [HttpPut]
    public JsonResult Put([FromBody] StudentViewModel studentViewModel)
    {
        //...
    }

This is the process in steps:

The view makes an ajax request to the Controller Api. This request has all the property's of the StudentViewModel so it can be parsed in the Controller Api.
The Controller Api takes in the information and will parse it to the StudentViewModel
The Controller Api asks the repository to create a new student from the StudentViewmodel.
The repository will create a new student from the information in the StudentViewModel

I have my data acces layer wrapped in repository pattern. It will look something like this:

Controller API

    [HttpPut]
    public JsonResult Put([FromBody] StudentViewModel studentViewModel)
    {
        using (var db = new UserQuery(DatabaseContext.GetInstance()))
        {
           // creates a user based on the information in the viewmodel
           db.Students.CreateNew(studentViewModel);
        }
    }

But for some reason I do not like this approach. Because I now have my View layer and data layer depend on the same viewmodel. The view is heavily bound to
the StudentViewModel because the data it provide should be convertible and this same VieModel is used for the database to create a new user.

Question

Is there a better way for this scenario? Or is this just fine.

Best Answer

ViewModel objects and Model objects are not the same thing.

The purpose of a Model object is to model something in your domain. The purpose of a ViewModel object is to model something in your view.

Do you see the difference?

The reason this doesn't look right to you is that the Model shouldn't know anything about your ViewModels. Your repository should only know about Models.

There are a couple of ways you can fix this. One way is to build a Model object from the studentViewModel in your controller, and pass that to your repository. The other way to do it is to add a service layer that accepts ViewModel objects and translates them into Model objects for your repository.

Related Solutions

C# – Hierarchical View/ViewModel/Presenters in MVPVM

So I think you have some minor violation of MVVM | MVPVM patterns due to linkage you're creating between the views. Neither pattern is all that verbose with respect to child windows though, so it's a bit of a murky area.

I think it's worth pointing out that the big advantage of MVPVM vs. MVVM is because of separating out business logic. The VM becomes a data container and the P handles logic plus DAL access. Bill Kratochvil's article on MVPVM was a very good read.

Bill makes a comment regarding child windows and re-use that I think is apt:
In cases where a Presenter can be reused across enterprise applications, it’s likely a module would be better suited for the task—that is, you could create a login module (project) that could be reused by all of your enterprise applications.

Which kind of reinforces that you're in murky territory with two child components.

Regardless of MVVM or MVPVM, I think you would need either

B-VM and C-VM when using MVVM
B-P and C-P and B-VM and C-VM when using MVPVM

because they are functionally separate from A. If they're not functionally separate, then why do they need their own Views?

I think the challenges you bring up with swapping ViewB and ViewC is because there is some blurring between object ownership and responsibilities. Which is really just another way of asking if B and C are functionally separate from A or not. If they are, then make them that way and if not, then don't set them up as independent.

For lightweight stuff without a lot of business logic that could be re-used, I think that MVPVM is more effort than it's worth with MVVM. That's clearly a generality, and the business logic of your application may lend itself to being expressed more elegantly with MVPVM. Based upon your question though, it sounds like MVVM may be sufficient for what you need.

MVC – Strongly Typed Views and ViewModel

I also prefer strongly-typed views with dedicated ViewModels.

To get around the problem you are seeing I sometimes construct my ViewModels like:

public class UserCarsViewModel
{
    public User User { get; set; }
    public List<Car> Cars { get; set; }

    public bool SomeCalculationIDontWantToHaveToDoInRazor
    {
        get { return _some mildly complex code here_ }
    }

    public List<Car> SomeFilteringIDontWantToHaveToDoInRazor
    {
        get { return _some mildly complex code here_ }
    }

    public bool SomeOtherConditionIDontWantToHaveToDoInRazor
    {
        get { return _some mildly complex code here_ }
    }
}

All of the more-than-dead-simple processing that would otherwise have to be in the view code (Razor) would be placed in the ViewModel, where is can be more easily tested. The Razor code is, in turn, much easier to read.

But, my Models are also in there, ready to be used as-is. If the Models change, but the changes don't affect my ViewModel calculations, my ViewModels don't need to change.

My controller ends up looking like:

public ActionResult Index() 
{
    var viewModel = new UserCarsViewModel();
    viewModel.User = db.Users.Where(u => u.UserId = userId);
    viewModel.Cars = db.Cars.Where(c => c.OwnerId = userId).ToList();
    return View("UserCars", viewModel);
}

Best Answer

Related Solutions

C# – Hierarchical View/ViewModel/Presenters in MVPVM

MVC – Strongly Typed Views and ViewModel

Related Topic