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.
Related
I'm completely new to MVC, moving from Webforms which I know well.
I've got the basics and now trying to work with a database. I can send data to the view no problem but how do I get the edited back?
I'm seeing lots of examples like this:
public ActionResult Update(MyObject myObject)
{
//do database EFW here
}
I can't work out how you get the data from the web-form(view) into myObject. I'm not doing anything clever I have followed a few examples on line but none explain how this mechanism works.
For the form I'm using #Html.BeginForm and helper functions (Html.TextBoxFor) etc, to create my form fields. The problem is now I can't get the edited data back so I can update my data. I hit the right controller action.
The only thing that's different is my form a is a partial view inside a bootstrap dialog.
UPDATE
Well I finally have a object back in my action method, however it doesn't have the key field populated, only the things on the form so I still can't save it (as an update) because I don't know which one it is.
I get and send this object to the view
var diary = new mySQLEntities().Diaries.Single(d => d.DRefno == Id);
and all is good, then what I want to do is this, or something similar
public ActionResult DiaryItemUpdate(mymvc.Diary Diary)
{
mySQLEntities db = new mySQLEntities();
db.Diaries.Add(Diary);
db.SaveChanges();
return RedirectToAction("Index", "Home");
}
[Bind(Include = ... )] doesn't work, it just deletes ALL the properties, even the ones I was getting back.
All the examples I look at seem to do the same thing as I'm doing but it just doesn't work.
I thought this was going to be easy but it isn't. I looked at EF a while back and ditched it for this very reason. It says it makes development easy, it's making it a lot harder for me. I can see why I stuck with web-forms for so long.
Any properties you pass in need to be instantiated in the form if you want them passed back. You need to add the ID of the object as a hidden form element:
#Html.HiddenFor(model => model.ID)
This will ensure that the ID for the object you sent to the view gets posted back.
I'm trying to build a simple MVC application with VS and Entity Framework, i have few questions.
I want to add some default values to my model, i can do that by
including default values to constructor like this:
public Worker()
{
WorkerActive = true;
}
But default controller code is like this, and it's not returning anything
public ActionResult Create()
{
return View();
}
If i change that to this, it works but i'm not sure if i'm doing something wrong:
public ActionResult Create()
{
return View(new Worker());
}
Are there any problems here?
I have a combobox with all workers in it, i want to show some
records based on the selection. For example, i want to show all
records where WorkerId=ComboboxValue. I can do this easily
by using this:
workers = m.Workers.Where(w => w.BranchId == curUser.BranchId).ToList<Worker>();
But it's in a view. Is using
statements like where in view a bad practice? I can add a new method
to controller like getUsersByBranch(BranchId) and use that.
What's the right way to do it?
Thanks
1) I'd argue that your models should be as stupid as possible, just properties and metadata. Your controller can certainly have logic in it to manipulate the model, though. That's what it's for - to return the model to the view, however you see fit:
public ActionResult Create()
{
var model = new Worker { WorkerActive = true };
return View(model);
}
Plus, you won't have to worry about needing different default values in a different controller.
2) The view is 'supposed' to be pretty dumb too. But as with all best practices, it really comes down to the overhead of refactoring and the potential gain. No, that code probably shouldn't be in your view. Ideally, if it's required by the view, it'd be a property of some sort on your model, that you controller has set up.
The logic with the 'best practice' of simple views is that it can get overly convoluted very quickly if you keep doing this, leading to spaghetti code. But like I said, you should try things and see if you like them sometimes, instead of simply going along blindly with best practices.
by 'property on your model' I mean:
public class CreateModel
{
public List<User> UsersInBranch { get; set; }
}
then your controller can fill it in, like above. Keeps your view cleaner, and lets the controller perform it's intended functionality. With MVC and Razor, logic in your view is not really in your view (in my mind), because it's still running server side. It feels like mixing server and client side operations to me.
public ActionResult Create()
{
return View(new Worker());
}
No problems in here, but Worker is a Entity? Maybe you should separate infrastructure (ef mapping) code from presentation (mvc).
workers = m.Workers.Where(w => w.BranchId == curUser.BranchId).ToList<Worker>();
Don't do this in your View. It would be better if you move this code to repository. Take a look at the good paper from Martin Fowler about this pattern:
http://martinfowler.com/eaaCatalog/repository.html
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).
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.
I'm relatively new to view models and I'm running into a few problems with using them. Here's one situation where I'm wondering what the best practice is...
I'm putting all the information a view needs into the view model. Here's an example -- please forgive any errors, this is coded off the top of my head.
public ActionResult Edit(int id)
{
var project = ProjectService.GetProject(id);
if (project == null)
// Something about not found, possibly a redirect to 404.
var model = new ProjectEdit();
model.MapFrom(project); // Extension method using AutoMapper.
return View(model);
}
If the screen only allows editing of one or two fields, when the view model comes back it's missing quite a bit of data (as it should be).
[HttpPost]
public ActionResult Edit(int id, ProjectEdit model)
{
var project = ProjectService.GetProject(id);
if (project == null)
// Something about not found, possibly a redirect to 404.
try
{
if (!ModelState.IsValid)
return View(model) // Won't work, view model is incomplete.
model.MapTo(project); // Extension method using AutoMapper.
ProjectService.UpdateProject(project);
// Add a message for the user to temp data.
return RedirectToAction("details", new { project.Id });
}
catch (Exception exception)
{
// Add a message for the user to temp data.
return View(model) // Won't work, view model is incomplete.
}
}
My temporary solution is to recreate the view model from scratch, repopulate it from the domain model, reapply the form data to it, then proceed as normal. But this makes the view model parameter somewhat pointless.
[HttpPost]
public ActionResult Edit(int id, ProjectEdit model)
{
var project = ProjectService.GetProject(id);
if (project == null)
// Something about not found, possibly a redirect to 404.
// Recreate the view model from scratch.
model = new ProjectEdit();
model.MapFrom(project); // Extension method using AutoMapper.
try
{
TryUpdateModel(model); // Reapply the form data.
if (!ModelState.IsValid)
return View(model) // View model is complete this time.
model.MapTo(project); // Extension method using AutoMapper.
ProjectService.UpdateProject(project);
// Add a message for the user to temp data.
return RedirectToAction("details", new { project.Id });
}
catch (Exception exception)
{
// Add a message for the user to temp data.
return View(model) // View model is complete this time.
}
}
Is there a more elegant way?
EDIT
Both answers are correct so I would award them both if I could. The nod goes to MJ however since after trial and error I find his solution to be the leanest.
I'm still able to use the helpers too, Jimmy. If I add what I need to be displayed to the view bag (or view data), like so...
ViewBag.Project= project;
I can then do the following...
#Html.LabelFor(model => ((Project)ViewData["Project"]).Name)
#Html.DisplayFor(model => ((Project)ViewData["Project"]).Name)
A bit of a hack, and it requires the domain model to be decorated with System.ComponentModel.DisplayNameAttribute in some cases, but I already do that.
I'd love to call...
#Html.LabelFor(model => ViewBag.Project.Name)
But dynamic causes a problem in expressions.
After some trial-and-error (aka code it, then hate it) learning, my currently preferred approach is:
I use view-models only to bind input fields. So in your case, if your view is only editing two fields, then your view-model will only have two properties. For the data required to populate the view (drop-down lists, labels, etc), I use the dynamic ViewBag.
I believe that displaying the view (i.e. populating anything the view needs to display), and capturing the posted form values (binding, validation, etc) are two separate concerns. And I find that mixing the data required to populate the view with that which is posted back from the view gets messy, and creates exactly your situation more often than not. I dislike partially populated objects being passed around.
I’m not sure how this plays out with Automapper (for mapping the domain object to the dynamic ViewBag) though, as I haven’t used it. I believe it has a DynamicMap method that may work? You shouldn’t have any issues auto-mapping the posted strongly-typed ViewModel onto the Domain object.
If I understand correctly, your viewmodel probably looks very similar to your domain entity. You mentioned that the viewmodel can come back mostly empty because only certain fields were editable.
Assuming you have a view where only a few fields are available for edit (or display), these are the only fields you should make available in your viewmodel. I usually create one viewmodel per view, and let either the controller or a service handle the user's input and map it back up with the domain entity after performing some validation.
Here's a thread concerning best-practices for viewmodels that you might find useful.
Edit: You can also accept a different view model in your Edit/POST action than your Edit/GET action serves up. I believe this should work as long as the model binder can figure it out.