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)