Is the View in MVC supposed to know the about the Model Data?

Question

I've researched about MVC for a while and similar questions like this and this .

They, however doesn't answer my question. In a lot MVC examples (Both ASP.NET MVC and JAVA MVC) They usually provide the Model with fields EG (Name, Age etc) and then allow the view to "read" those fields.

But from what I've understood is that the View should not know about the Model, cause if the View does then it's not (correctly) encapsulated.

Pictures however shows that the View knows about the Model to display correct data.

If I understood correctly is that the Model can be business logic for a system and the View is not supposed to be connected to that.

Lets say that my Model fetch data from a database, then it's still my Model that is my business logic and not the database or am I thinking wrong?

So my questions is

• Should the View know about the Model to use correct data?
• Is the Controllers job to fetch data from EG a database and create a Model from that, and the View should use the Model data for display?
• What is Model Business Logic? (Please don't use fields to explain)

Answer 1

a lot of this is open to interpretation. There are a number of approaches and is down to which ever suits you best. My approach is below if its some help.

Should the View know about the Model to use correct data? Yes. The view has a model import directive for it to bind to when it's rendered. If the view didn't know anything about the model it was accessing then how could it bind to the data.

Is the Controllers job to fetch data from EG a database and create a Model from that, and the View should use the Model data for display? No, the controller should no nothing about the implementation of the data layer. The controllers only job should be to invoke the services that it needs to build up the view model.

What is Model Business Logic? (Please don't use fields to explain) Not to sure about the exact term "Model Business Logic". Model can be used to describe domain models or in this case View models. Business logic are operations you perform on business or domain model objects populated by some service.

The way how i handle ViewModels and business logic as you say is to separate out the domain model, eg Customer or Order in a separate dll and have those domain objects populated by a service. Then your View Model becomes a composite of domain model objects.

So in all.. the controller makes a call out to services that consume datalayers which in term return you populated domain objects. These can then be used to populate your view model which is then used by the view.

I've added below a very simplistic look at approach which will hopefully point you in the right direction.

public class MyController
{
    [HttpGet]
    public ViewResult GetCustomer(int customerID)
    {
        var myViewModel = new CustomerViewModel();
        var myService = new MyServiceLayer();

        var myCustomerDetails = myService.GetCustomerDetails(customerID);

        myViewModel.Customer = myCustomerDetails;

        return View("CustomerDetails", myViewModel);
    }
}

public class CustomerViewModel
{
    public CustomerDomainObject Customer { get; set; }
}


public class CustomerDomainObject
{
    public string Name {get;set;}
}

public class MyServiceLayer
{
    public CustomerDomainObject GetCustomerDetails(int customerID)
    {
        var myCustomer = new CustomerDomainObject();
        var dataLayer = new MyDataLayer();
        var myCustomerData = dataLayer.GetCustomerDetails(customerID);

        var myDataRow = myCustomerData.Tables[0].Rows[0];
        myCustomer.Name = myDataRow["Name"].ToString();

        return myCustomer;
    }
}

public class MyDataLayer
{
    public DataSet GetCustomerDetails(int customerID)
    {
        //Execute proc etc...
        return new DataSet();
    }
}

Answer 2

In ASP.NET MVC you have strong typed views. This is a razor thing that let you access to your model properties easily when you are building your view. You will easily notice this since IntelliSense will work whenever you are trying to access a property like @Model.Name . If it should or not be strong typed, IMHO it just relay on what you need, there are not cons on using strong typed views. It will help you big time whenever you code your views, and you will have less runtime errors for sure.

For 'Model Business Logic' I would say that you can for sure have a lot of Logic in your model, but that is not as simple as it sounds. You will probably have to work with patterns and have small classes which responsible for one thing.

Look at this link: https://msdn.microsoft.com/en-us/library/hh404093.aspx

Answer 3

Generally speaking it's a good idea to completely separate the domain model from its view representation. Domain model contains the entire business logic, which can be quite complex. Also, the presentation layer usually requires extremely simplified objects (just data structures, without any business logic). Specific view technologies might apply heavy restrictions to the objects. Besides of that, we often change/aggregate domain objects to suit the final user specific needs (by creating specialized DTOs). Therefore, since presentation and domain layers are so distinct (and domain model should never depend on view), I often completely separate them. This allows to create a more supple design.