So, I’m designing an MVC framework. In the name of keeping everything statically typed and non-magical, I’ve come to quite a problem with “automatically” passing models to a controller.
So, traditionally, I usually see no more than one model used at a time in a controller as far as automatic-population.
For instance, take this tutorial. There is a method like this in the controller:
[HttpPost]
public ActionResult Create(Movie newMovie)
{
if (ModelState.IsValid)
{
db.AddToMovies(newMovie);
db.SaveChanges();
return RedirectToAction("Index");
}
else
{
return View(newMovie);
}
}
My concern is passing a Movie model to the Create method which is populated by FORM values “magically”. In my API, this should be easily possible and would look something like this at routing:
var movie=router.Controller((context) => new MovieController(context))
.WithModel(() => new Movie());
movie.Handles("/movie/create").With((controller, model) => controller.Create(model));
My concern with this is that it is much harder to have multiple models because of limitations with C#’s type system. Of course, the controller can always manually create the models from FORM values and such, but it’s not nearly as pretty.
So, my question: Is it common to have something like Foo(Movie model) and Bar(SomeClass model) in the same controller class? Is it a good idea for me to attempt to support such a scenario, or is it just a symptom of putting too much unrelated logic in a single controller?
Note: if you’re concerned about how this fluent API is even possible, the answer is generic delegates.. lots and lots of generic delegates 🙂 (but so far very little reflection)
1
In short No. I dont think you can ever assume that a controller will only ever use one primary model.
Most MVC applications will end up with a lot of different models that are used all over the place.
Using your Movie example if you only needed to use a couple of the items out of your Movie model then you would probably create a smaller view model that was mapped from the main view model as it will be quicker and use less resources.
If you are using Entity Framework then this can easily be achieved by overriding the AutoMapper setup.
Hope this helps a bit.
This doesn’t directly answer the question in the title, but it might give you some food for thought.
The snippet you have there looks like its from MVC3. In MVC3 there’s an important distinction between domain/database/application models and view models. While the controller can use many domain models to process requests (build views, send stuff to the db and whatnot), it can only bind one view model to a view, and that view can only send back one view model on post-back. So sending multiple domain models to the action would actually involve an intermediary view model which would bind to the view and have references to the domain models.
In my opinion, the thing that most of the simpler tutorials do wrong is that they use the domain model as a view model, which is fine on it’s own, but I believe that there’s a conceptual distinction here that needs to be noted.
When working with complex forms/views in MVC3, you’ll more often that not, need separate view models which will be composed of multiple domain models, and/or flatten some of the domain object graph to make for easier representations in the view and handling of post values.
Even then, some more complex forms make you fetch individual post values, either from the request itself or by setting another action parameter with the expected form field name.
7
Earlz in my humble opinion first i think that a controller should control a sub-section of your project let’s say the messaging system or in your case the movie domain. So in essence i don’t think that it’s wrong to use the different models required to achieve your goal in a controller. Also, you can use your domain model without sub-classing like entity framework code first developers do. So the most important thing is that you plan your controllers in a way that all the action methods in it will perform a set of related function.