What Goes into the "Controller" in "Mvc"

What goes into the Controller in MVC?

In the example you suggested, you're right: "user clicked the 'delete this item' button" in the interface should basically just call the controller's "delete" function. The controller, however, has no idea what the view looks like, and so your view must collect some information such as, "which item was clicked?"

In a conversation form:

View: "Hey, controller, the user just told me he wants item 4 deleted."

Controller: "Hmm, having checked his credentials, he is allowed to do that... Hey, model, I want you to get item 4 and do whatever you do to delete it."

Model: "Item 4... got it. It's deleted. Back to you, Controller."

Controller: "Here, I'll collect the new set of data. Back to you, view."

View: "Cool, I'll show the new set to the user now."

In the end of that section, you have an option: either the view can make a separate request, "give me the most recent data set", and thus be more pure, or the controller implicitly returns the new data set with the "delete" operation.

What is the role of Controller in MVC model?

Wikipedia states very simply: The controller, accepts input and converts it to commands for the model or view.

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

What is the job of controller in MVC?

You don't need a controller because your example is trivial.
An example from a real case scenario:

Suppose you have a CAD application. The CAD application is arranged as MVC. You have:

• a view which is responsible for drawing the current model, and provide clickable entities.
• a model, which keeps the current data to be represented
• a controller, whose role is to get the events from the view, and convert them into proper entities so to modify the model.

For example, the user clicks on a square and deletes it. The controller will receive the event from the view, creates an object representing a command (via the Command pattern), add it into a queue for undo capability and executes the command. The command will then modify the model, but the responsibility of translating view events into the complex machinery that modifies the model is under the responsibility of the controller.

Of course you could say, why isn't the view creating Command objects then? well, nobody forbids you that, but you would end up having presentation logic mingled with operational logic. This goes against good design, although for the most trivial cases, you could live with this design. For example, if your CAD application allows you to display the list of objects both as a 3D representation and as a list of entities, and you could delete from both, you clearly see that either the two views both implement the same logic to handle the command pattern (bad design), or they just channel the same message to a common controller (good design, the MVC).

MVC, what goes where

Short answer: no, you are not doing it the right way, or even slightly correct-ish way.

The MVC design pattern is all about separation of concerns. You separate the model layer from presentation layer - to split the domain business logic from how it is demonstrated.

In presentation layer you split the components that are responsible for user interaction (controllers) from those that govern the UI creation (views).

_{The model layer too is subject to some separation, though that usually is not covered in "mvc for beginners by beginners" blog posts. I wrote a short description in an earlier post. But if you want to actually understand how to implement model layer, you will have to read Folwer's PoEAA.}

In classical MVC (which you cannot use for web) and Model2 MVC patterns the view request all the data that it needs from the model layer. The controller only changes the state of the model layer and the current view by applying user input to them.

In the simplest implementations of other MVC-inspired design patterns (MVVM and MVP) the controller-like structures (ViewModel and Presenter - respectively) provide the view with the data from the model layer. That also means that having a viewmodel inside a controller makes no sense whatsoever. You can read more about MVP pattern in this publication.

_{P.S. also, why are you injecting DB connection in the controller when all you will do with it is to pass it along? That code fragment is violating LoD. If you need to acquire structures from model layer inside a controller, you should be injecting a factory instead.}

Correct use of Model vs Controller in MVC / ASP.NET MVC

I personally subscribe to the logic of Number 3, allowing the controller to populate the Model (or View Model as is sometimes differentiated).

• I have my views dumb and only displaying data.
• I have my View Models store the information that the View will need, occasionally exposing 'get only' properties that format other properties into a nicer format. If my model needs access to my services, then I feel I'm doing something wrong.
• The controllers arrange and gather all the information together (but do no actual work, that is left for the services.

In your example, I would have my controller action similar to:

public ActionResult Index()
{
    IndexViewModel viewModel = new IndexViewModel();
    viewModel.ProductSelectList = new SelectList(Service.GetProducts(), "Value", "Name");
    return View(viewModel);
}

and my view model similar to:

public class IndexViewModel()
{
   public SelectList ProductSelectList { get; set; }
   public int ProductID { get; set; }
}

With the appropriate part of the view looking like:

@Html.DropDownListFor(x => x.ProductID, Model.ProductSelectList);

This way I'm content that I know where to look if there is an issue with anything and everything has a very specific place.

However, there is no correct way as seems always to be the case with these things. Stephen Walther has a good blog series on MVC tips. In one he talks about the View Model emphasis and although not a SelectList he populates, the SelectList is still data in much the same way his list of products is.

ASP.NET MVC - Job of Controllers

Do you have dedicated ViewModels and Poco-Models? If this is the case you can handle the data from the services inside the ViewModel.
I am quite happy with this uproach.

public class PackageViewModel()
{
    public PackageDetail{get;set;}
    public int PackageID{get;set;}
    public List<Package>Packages{get;set;}
    public string SomeFilterCriteria{get;set;}

    publlic void FillPackageList(IPackageService packageService)
    {       
        Packages = packageService.GetPackages(SomeFilterCriteria);      
    }
}

In Controller:

public ViewResult ListPackages(PackageViewModel model)
{
    model.FillPackageList(PackageService);
    return View("ListPackages",model);

}

I dont understand what you mean by "view model builders".

---

Related Topics