We Keep Coding

c# MVC Coding pattern for maintaining model properties

Right, so a) I'm not sure if this is the right forum for this question, I failed to find a better suggestion, and b) I couldn't find an answer to a question I can't believe I haven't asked before:
So if I have a model, standard form to fill in and it errors so I throw it back to the user, how do I, or how SHOULD I, structure the code to make sure all the supporting properties are constructed?
Example:
public ActionResult DoThing()
{
var model = new DoThingModel();
model.Things = ThingService.FetchThings();
//Do Other Things
return View(model);
}
The fairly standard GET action
[HttpPost]
public ActionResult DoThing(DoThingModel model)
{
var valid = ThingService.ValidateThing(model);
if(!valid)
{
model.ValidationMessage = "Ohh no validation failed";
model.valid = false;
return View(model); //I have't rebuilt model.Things with ThingService.FetchThings()
}
else
{
return RedirectToAction("Success");
}
}
So if the thing is valid redirect to the success page, but otherwise return the form (contained within the model) to the user with a validation message. Problem is my form page has things on it and I haven't populated the model with it.
Now, this is a very simple example and I could just pass back things in the form, or duplicate the line of code that populates it. But imagine I have a much more complicated model, with breadcrumbs, multiple properties that need populating. Code duplication = bad, so how SHOULD I be making sure the model has everything I need before passing it back? I thought about creating a service but it's a service with one function. I thought about using a constructor, but that doesn't play well with model binding. I thought about creating a DoThingModel.Init() that does all the work, but putting code like that inside a model class seems dirty. I played around with a private function in the Controller that filled in all the required properties, but this seems dirty again.
I feel like there should be a standard code pattern that goes => Create New Model => Make sure Model has everything that supports the page => return Model => validate Model => re-apply any properties => return Model => repeat until valid.
Like I said in the intro, this must be a standard thing somewhere, but I can't find it.

Returning multiples of the same model to view [duplicate]

I've been able to successfully return a model to a view and display the results in a strongly-typed fashion.
I have never seen an example where multiple models get returned. How do I go about that?
I suppose the controller would have something like this:
return View(lemondb.Messages.Where(p => p.user == tmp_username).ToList(), lemondb.Lemons.Where(p => p.acidity >= 2).ToList());
Does MVC let you return multiple models like that?
And then in the view I have this line at the top of the file:
#model IEnumerable<ElkDogTrader.Models.Message>
And I frequently make calls to "model" in the view.
#foreach (var item in Model)
If there were 2 models, how would I refer to them separately?
Is this possible with multiple models, or is this why people use ViewBag and ViewData?

You can create a custom model representing the data needed for your view.
public class UserView
{
public User User{get;set;}
public List<Messages> Messages{get;set;}
}
And then,
return View(new UserView(){ User = user, Messages = message});
In the view:
Model.User;
Model.Messages;
The ViewBag is useful because it is dynamically typed, so you can reference members in it directly without casting. You do, however, then lose static type checking at compile time.
ViewData can be useful if you have a one-off on your view data types and know the type and will be doing a cast in the view anyway. Some people like to keep the actual typed view pure in a sense that it represents the primary model only, others like to take advantage of the type checking at compile time and therefore make custom models needed for the view.

I believe ViewModel should be the way to go. Within the customary ViewModel, you can reference other models or define all the related domain models in the viewModel itself.

Weird Behaviour with models

So this is strange. I have a model composed of person and List<person>. when the user submits the view back to the controller, person is add to the List<person> and then we clear out all the person fields by the means of a person=new Person();.
I would expect that when return to the view, all the person fields are cleared out and the view is a "fresh" start. However, for some strage reason I cannot figure out, most of the fields for person are still filled out with the previous values (even after the person=new Person();).
The model is a complex model, composed of several "objects of objects", and some of the objects inherit from other objects. Still, I can't understand why the view still shows values from previous posts.
EDIT !!!!!
I am posting via a regular form post (HTML.BeginForm()). So here is my controller:
[HttpPost]
[ValidateAntiForgeryToken()]
public ActionResult sendInscriptorRequest(inscriptionModel _model)
{
var _umbracoModel = Umbraco.TypedContentAtRoot().FirstOrDefault();
_model = bllInscripcion.fillModel(_model);
_model = _model.Map(_umbracoModel);
if (_model.formAction == "addParticipants")
{
_model.participants.Add(_model.newParticipant);
_model.newParticipant = new participantModel();
_model.ui.participants.btnTotalParticipantsNumber += 1;
return View("addParticipants", _model);
}
else
{
_model.newParticipant = bllInscripcion.preFillParticipantContactWithInscriptorContact(_model);
return View("formularioInscripcion2", _model);
}
}

You trying to return the view with the model from the POST action method. That won't work because the intended behavior is to return the model state that was posted so the user can make corrections.
If you're posting data and then want to return an empty view you should redirect to the GET action method that returns the initial state of the view. It's known as a Post-Redirect-Get pattern.
http://en.wikipedia.org/wiki/Post/Redirect/Get
Following this pattern will also solve the problem of the user refreshing the page following the POST and getting that annoying dialog that says "You're about to resubmit data. Are you sure?" to which the user always responds "Yes" and then your system has to deal with the potential duplication.

Explanation of the problem:
This is because of ModelState. By default, MVC will retain the model state within a post action if you're returning the same view. To prevent this, simply clear it before returning the view:
ModelState.Clear();
This will mean that whatever model you pass back to the view will be used, not the one stored in model state.
DISCLAIMER:
You should use ModelState.Clear only when needed. Judging by your code, you don't need to use it. Simply redirecting to another page after you have performed the necessary logic is the better thing to do here (as per the PRG pattern).

When/Where/How to populate property of model in MVC

I have a model that contains an Address property and Latitude/Longitude properties. The model is populated in a "Create" view, where they put in most of the other fields. I populate the Lat/Lng using the Google Maps API geocoding functionality based on the entered address (no sense in making them put this in manually).
My big question is where should this be done. The code below works, but I think it's pretty clunky. Any thoughts on a better way to integrate this behavior? Should it be in the controller? Should it be part of some internal model mechanism?
[HttpPost]
public ActionResult Create(Church church)
{
try
{
if (ModelState.IsValid)
{
string address = string.Format("{0},{1},{2} {3}",
church.Street + church.Street2, church.City,
church.Region, church.PostalCode);
JObject jsonResult = GoogleApiHelper.GetAddressGeocodeData(address);
//Handle some error states here...
if (jsonResult["results"].Count() == 1)
{
church.Latitude = jsonResult.SelectToken(
"results[0].geometry.location.lat").Value<double>();
church.Longitude = jsonResult.SelectToken(
"results[0].geometry.location.lng").Value<double>();
unitOfWork.ChurchRepository.Insert(church);
unitOfWork.Save();
return RedirectToAction("Index");
}
}
}
catch (DataException)
{
//Log the error (add a variable name after DataException)
ModelState.AddModelError("", "Unable to save changes.");
}
return View(church);
}

You could use a repository layer to abstract the access to the Google API and then invoke this repository from the controller to give you an already populated model. This way if tomorrow you decide to use Bing instead of Google all you have to change is the implementation of the repository. No need to touch your controller or model logic.

You could write a custom model binder and put all of your Google API code in there. That way your controller will be completely oblivious to your data access.
Here is a tutorial on custom model binders:
http://buildstarted.com/2010/09/12/custom-model-binders-in-mvc-3-with-imodelbinder/

The main question is are you going to create churches anywhere else?
If not then this is a perfectly acceptable place to put the code.
If you are then put the code into a ChurchService which can be called from both places. That way you can Keep to DRY (Don't Repeat Yourself) principles without over complicating your code.

ViewBag as a holder of session models

This is more of a high-level question than anything else.
I have a MVC project which, among other things, manages users.
I am currently sticking to a more strict approach that on my view pages I only use a model which is declared, meaning that I have a:
#model MVCApp.Models.SomeModel
At the top of each View.cshtml
There are some pages that require more than 1 model. At this point I consolidate the 2 models into 1, and send it to the view as one model.
Here comes the tricky part. Let's say I have some model which holds the user data. That user data is stored in the session cookies (typical Forms Authentication). It seems weird to me that I now have to wrap each and every model I use with my own model that holds both the User Model and the model which I want to use inside that View.
The question that I ask myself is why not pass the User Model to the ViewBag and use it inside the View. Why is that considered to be bad practice? It allows me to attach that model to every page without having to ultimately duplicate all my models.
I'd love to get some guidance. I might be looking at this the wrong way. Any help will be much obliged.
Thanks,

There are a couple of reasons why ViewBag should be avoided:
ViewBag is weakly typed
You don't get Intellisense in the view
Your view is a mixture of ViewBag and a view model and your view gets information from different places instead of centralizing everything into a strongly typed view model
ViewBag doesn't work with strongly typed helpers and expressions because dynamic types cannot be used with extension methods (that's not a limitation of ASP.NET MVC, it's .NET => you cannot dispatch extension methods on dynamic types)
Due to this weak typing nature of ViewBag you will have to cast in your views turning them into spaghetti code because HTML helpers expect specific types to be passed as arguments
... this list goes on (I really don't have time to fill it but it is very large list)
So now that we know that ViewBag is bad and shouldn't be used there are different ways you could solve this requirement by using view models.
One possibility is to use the Html.Action helper which allows you to insert some portion of HTML in the view by going through a full Controller/Model/View lifecycle. This way you could have a commonly used widget without interfering with your main view model.
Another possibility is to have a base view model which will contain a property representing user details and which will be populated by a custom global action filter that could executed everytime a controller action has finished executing and returned a view result. The action filter could intercept this view result, read the authentication cookie information and set the view model property. This assumes that all your view models derive from the common base view model. This obviously makes sense if you need to display this user information on each page.
For example:
public class UserInfoInjectorAttribute : ActionFilterAttribute
{
public override void OnActionExecuted(ActionExecutedContext filterContext)
{
var result = filterContext.Result as ViewResultBase;
if (result == null)
{
// the controller action didn't return any view result => no need to continue
return;
}
var model = result.Model as BaseViewModel;
if (model == null)
{
// the controller action didn't pass a model or the model passed to the view
// doesn't derive from the common base view model that will contain
// the user info property => no need to continbue any further
return;
}
model.UserInfo = ... go ahead and read the forms authentication cookie
userData portion and extract the information
you are looking for
}
}
Now all that's left is to register this action filter as a global action filter and it will be applied on all controller actions.
Now if all your view models derive from this BaseViewModel you will know that once you arrive in the view the UserInfo property will be populated with the relevant information without polluting all your controller actions with code that does the fetching of this property. And still you get strong typing in the view => no ViewBag (youpeeee).
Of course depending on your specific scenario there might be other ways to achieve that (obviously not involving any ViewBag).

You can an ActionFilterAttribute and in those Actions that load views which needs specific ViewBag items, you initialize them.
I don't recommend it, as it will be harder to mantains, but will be a generic approach which may solve your problems.