Persisting Dropdown information when ModelState is not valid - c#

I'm having some issues with my DropDownLists, because when I post the information and my Model is not valid it comes back "empty" to the page triggering an error exactly like this question.
I've used the solution proposed there and it fixed my problem. Anyway, I wanted to avoid querying the database every time my ModelState is not valid and I came with this approach. I would like to know if it is valid or if there are better ways to do it now, considering that instead of MVC2 (which was the MVC version from the question) I'm now using MVC 5, maybe they added something new to tackle this.
What I've done was to use the TempData to persist the information when my model is not valid.
public class ViewModel
{
[DisplayName("Project")]
public int ProjectID { get; set; }
public List<SelectListItem> Projects { get; set; }
//Other fields
}
Now my Create() Action (that populates Projects)
[HttpGet]
public ActionResult Create()
{
ViewModel vmodel = new ViewModel();
vmodel.Projects = db.GetProjects(User.Identity.Name).Select(x => new SelectListItem { Text = x.Description, Value = x.Id }).ToList();
TempData["Projects"] = vmodel.Projects;
return View(vmodel);
}
And my post would be like this:
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create(ViewModel vmodel)
{
//Clear TempData (in theory will clear my tempdata when read, so if this controller redirects to another action my tempdata will be clear)
List<SelectListItem> projects = (TempData["Projects"] as List<SelectListItem>);
if (ModelState.IsValid)
{
//...
}
//If it got here it's going back to the screen.
//Repopulate the TempData (allowing it to exist one more trip)
TempData["Projects"] = projects;
vmodel.Projects = projects
return View(atendimento);
}
Is this approach a good one? Is there a better way to achieve that without querying the database every single time?
Thanks a lot!

You don't need to use TempData at all as you have a property in your view model to hold the dropdown items.
public ActionResult Create()
{
ViewModel vmodel = new ViewModel();
vmodel.Projects = GetProjects();
return View(vmodel);
}
private List<SelectListItem> GetProjects()
{
return db.GetProjects(User.Identity.Name)
.Select(x => new SelectListItem { Text = x.Description,
Value = x.Id }).ToList();
}
And in the view
#Html.DropDownListFor(s=>s.ProjectID,Model.Projects)
And in your HttpPost action, If ModelState is not valid, Reload the Projects collection again (because http is stateless)
if(ModelState.IsValid)
{
// to do :Save and redirect
}
model.Projects = GetProjects();
return View(model);
You may cache the Projects so that you do not need to hit the database every time, if you are too much worried about performance.

Personally, I wouldn't worry about querying the database each time for this kind of operation.
What if projects are added/deleted? This could be the reason the save failed (selected project deleted) and the user would never realise it.
I usually write a method to populate all of my view model's SelectListItems and then use this in my Get and in my Post if the validation fails.

Related

ASP.NET MVC: How to use multiple models in one View?

I have the following ViewModel that includes 2 other models:
public class ViewModel
{
public ViewModel1 viewModel1 { get; set; }
public ViewModel2 viewModel2 { get; set; }
}
My View looks like this:
#Html.TextBoxFor(m => m.viewModel1.NameOfCustomer)
#Html.TextBoxFor(m => m.viewModel2.ProductCategory)
And finally the controller:
public ActionResult CreateNewOrder(ViewModel viewModel)
{
Model1 myModel1 = new Model1()
{
NameOfCustomer = viewModel.viewModel1.NameOfCustomer
};
db.Orders.Add(myModel1);
db.SaveChanges();
return View(viewModel);
}
The problem is, if I want to take the data from my ViewModel to pass it to my actual model, it does not work. It just shows null as value. If I do the following change to my controller data is there but this does not work as it should:
public ActionResult CreateNewOrder(ViewModel viewModel)
{
// that works
viewModel.viewModel1.NameOfCustomer = "John John";
Model1 myModel1 = new Model1()
{
myModel1.NameOfCustomer = viewModel.viewModel1.NameOfCustomer
};
db.Orders.Add(myModel1);
db.SaveChanges();
return View(viewModel);
}
So I guess the problem is, my data from my view is not being send correctly to my ViewModel. I hope you guys can give me a hint what Im doing wrong.
Regards,
Edited following #Stephen Muecke's comment, doesn't sound like this is the case. However, I'll leave this answer here, as my first port of call would still be to check out the POST payload in the request to make sure it was going across the wire as expected, so this part may be useful
It looks like it's because the data coming into your MVC action, is essentially a flattened view model, whereas the model expected in the action is hierarchical.
If look at the network tab within your browser's dev tools, find the POST request being made, and check the payload being sent to the server.
Sounds like this is being posted:
{"NameOfCustomer": "SomePerson", ....}
Which won't be autobinding server-side to your model, because ViewModel does not itself have a NameOfCustomer property - instead, it's on a child object held in the viewModel1 property. So, autobinding would work if the following was being posted:
{"viewModel1": {"NameOfCustomer" : "SomePerson", ....}}
Solutions include:
1) construct the payload to post from JS yourself, ensuring the structure reflects the nested objects correctly as above
2) Create a flattened viewmodel, so all properties from ViewModel1 are held directly at top level in the ViewModel class
3) Create a custom model binder
Your code should properly carry the information to the controller(see a similar fiddle here)
The piece:
Model1 myModel1 = new Model1()
{
NameOfCustomer = viewModel.viewModel1.NameOfCustomer
};
db.Orders.Add(myModel1);
db.SaveChanges();
Are you sure you are doing the right thing here? You are creating a Model1 type variable and add it to the Orders in your database. Are you getting any errors? Maybe the right code should be something like:
Order myModel1 = new Order ()
{
NameOfCustomer = viewModel.viewModel1.NameOfCustomer
};
db.Orders.Add(myModel1);
db.SaveChanges();

Storing Model in Session VS Recreating It

Is there any danger to use one of the 2 following methods? Is there any best practice?
I'm wondering if I will hit a wall when there will be many user online at the same time on the website.
Storing Model in Session for later reuse
public ActionResult Index()
{
var model = new Model();
Session["Model"] = model;
return View(model);
}
[HttpPost]
public ActionResult Index(FormCollection fc)
{
var model = (Model)Session["Model"];
//Update stuff
return View(model);
}
Recreating it on every requests
public ActionResult Index()
{
var model = new Model();
return View(model);
}
[HttpPost]
public ActionResult Index(FormCollection fc)
{
var model = new Model();
//Update stuff
return View(model);
}
Each model :
might contain a lot of calls to the database (it can take some time to
initialize them)
might contain list of information (a lot of data)
Edit
Feels like most avoid trying to answer the question and got stuck on unimportant details to the question.
I accepted the only answer which was able to stay on topic.
Atavari answer is completely off topic and didn't understood the question at all.
Both of those methods are wrong. Your post action should receive the model, not a FormCollection object.
[HttpPost]
public ActionResult Index(Model model)
{
//Update stuff
return View(model);
}
And, you usually redirect to a different page after the Add/Update is successful, and only return the same View if there's validation error. So, your post action should look more like this:
[HttpPost]
public ActionResult Index(Model model)
{
if(ModelState.IsValid)
{
//Update stuff
//return to a different page or whatever needs to be done
//after a successful update
}
// If model is not valid...
return View(model);
}
UPDATE:
If there are properties in your model that are not posted to your action (like a SelectList for a dropdown), you'll only need them if you want to return the same View (normally when there's validation error). In that case you don't have to recreate your model. You just repopulate those properties.
Let's say your model has a property called Items. This is how your actions should look like:
public ActionResult Index()
{
var model = new Model();
model.Items = GetItems();
return View(model);
}
[HttpPost]
public ActionResult Index(Model model)
{
if(ModelState.IsValid)
{
//Update stuff
//return to a different page or whatever needs to be done
//after a successful update
}
// If model is not valid...
model.Items = GetItems();
return View(model);
}
It depends on how many users you really have. Using session can be comfortable and easy but scalability may become an issue.
If you use it just to improve performance, I would suggest you to use cache instead. Take care that objects in cache can expire so you have always to check whether they are still there. Cache is better than session because it is self optimized. If memory gets low it's automatically cleaned, while session variables are never cleaned (unless of course when session expires).

Post IEnumerable collections from view in mvc

I am developing an ASP.NET MVC application, populating dropdownlist to view working fine in get method. I am populating to view like this in my controller
[HttpGet]
public ActionResult CreateEmployeeFamilyDetails(EmployeeSuperClass employeeSuperClass, int i = 0)
{
employeeSuperClass.FamilyDetailsFields = new FamilyList();
employeeSuperClass.FamilyDetailsFields.familyMembersList.Insert(0, new EmployeeFamilyTable());
*employeeSuperClass.FamilyDetailsFields.employee_RelationTable = dt.GetRelations();*
*employeeSuperClass.FamilyDetailsFields.employee_BloodGroupTable = dt.GetBloodGroups();*
*employeeSuperClass.FamilyDetailsFields.employee_NationalityTable = dt.GetNationalities();*
return View("CreateEmployeeFamilyDetails", employeeSuperClass);
}
Please look into starred lines
In case if there is any errors in model am getting null reference
In post action method look like this
[HttpPost]
public ActionResult CreateEmployeeFamilyDetails(EmployeeSuperClass employeeSuperClass, string Command)
{
if (ModelState.IsValid)
{
return("some view");
}
else
{
return view(employeeSuperClass);
}
}
I know again we have to create instance to populate dropdownlist this is rubbish to do same again and again
Can anyone explain how to store dropdown list collection in view separately and post them also with model?
(note: employee_relationTable is IEnumerable collection and it is a relationtable type this table contains relation id and relationname fields and am using this table in this class like below
public IEnumerable<EmployeeRelationTable> employee_RelationTable { get; set; }
For rest also am using same approach
Can we post employee_RelationTable from view and how?
Please help and your help would be greatly appreciated
Assuming dt is a member field available to all methods, what you can do is DRY up the population of the DropDowns in the View Model in a separate method, e.g.
private void PopulateDropDownsOnViewModel(EmployeeSuperClass model)
{
model.FamilyDetailsFields = new FamilyList
{
employee_RelationTable = dt.GetRelations(),
employee_BloodGroupTable = dt.GetBloodGroups(),
employee_NationalityTable = dt.GetNationalities()
}
}
Which can be used in the Get:
[HttpGet]
public ActionResult CreateEmployeeFamilyDetails(EmployeeSuperClass employeeSuperClass, int i = 0)
{
PopulateDropDownsOnViewModel(employeeSuperClass);
return View("CreateEmployeeFamilyDetails", employeeSuperClass);
}
and in the Post (and any other controller actions which need the drop downs)
[HttpPost]
public ActionResult CreateEmployeeFamilyDetails(EmployeeSuperClass employeeSuperClass, string Command)
{
if (ModelState.IsValid)
{
return("some view");
}
else
{
PopulateDropDownsOnViewModel(employeeSuperClass);
return View(employeeSuperClass);
}
}
If the drop downs are static, you can also look at caching these to prevent wasted IO to the database.
But no, don't serialize the the data in the View somehow (remember WebForms ViewState?) or fetch data from the View directly - this violates the MVC paradigm - the controller is responsible for providing data for the View to render.

Persist SelectList in model on Post

In MVC4:
I have the following property in my model used for a dropdown list:
public SelectList Subjects { get; set; }
I set the Subjects property in my Index() Action on page load and return the model.
The dropdown gets populated just fine with the SelectListItems.
#Html.DropDownListFor(x => x.Subject, new SelectList(Model.Subjects, "Text", "Text", "Other"))
When I submit the form the Subjects SelectList in the model has changed to null. There has to be a simple way to persist this on HttpPost. I assume I want to submit and post this SelectList as well, along with all the form fields? How would I do this?
It is commonly accepted that you re-populate a SelectList after the Post action. Just extract it inside a method and call it in the Get and Post action.
Posting it back again to the controller is not the way to go. You can cache the items in the SelectList so you won't have to make a query to the data store twice.
Example:
public ActionResult Create()
{
var model = new SubjectModel();
PopulateSubjectList(model);
return View(model);
}
[HttpPost]
public ActionResult Create(SubjectModel model)
{
if (ModelState.IsValid)
{
// Save item..
}
// Something went wrong.
PopulateSubjectList(model);
return View(model);
}
private void PopulateSubjectList(SubjectModel model)
{
if (MemoryCache.Default.Contains("SubjectList"))
{
// The SubjectList already exists in the cache,
model.Subjects = (List<Subject>)MemoryCache.Default.Get("SubjectList");
}
else
{
// The select list does not yet exists in the cache, fetch items from the data store.
List<Subject> selectList = _db.Subjects.ToList();
// Cache the list in memory for 15 minutes.
MemoryCache.Default.Add("SubjectList", selectList, DateTime.Now.AddMinutes(15));
model.Subjects = selectList;
}
}
Note: MemoryCache uses the System.Runtime.Caching namespace. See: System.Runtime.Caching namespace.
Also, caching should be in a seperate layer between your controller (or business layer) and the data access layer, this is just for clarity.
Browsers only post back the selected values on the form elements. Also, its not a good idea to post back the values which can be retrieved from the data store. You would have to pull the items in the list just like you did while populating the list.
Also, MVC does not maintain the state of the page like .NET webpages as it does not have a view state. Developers are fully responsible for managing states of pages between the post backs, which is the essence of MVC design pattern.

Proper way to POST data MVC

Warning: This is my first web app.
I have 4 models, views and controllers. Lets call them A, B, C, D(ex. ModelA, ControllerA, ViewA). They are all basic views with list scaffolding.
/ControllerA/Index
User starts at ViewA and Selects an the first item, which redirects the user to ViewB
/ControllerB/Function?Aid=1
ViewB shows another list based on Selection from ViewA. Then the user Selects again is is redirected to ViewC
/ControllerC/Function?Aid=1&Bid=2
ViewC shows another list based on Selections from ViewA and ViewB. Then the user Selects again is is redirected to ViewD.
/ControllerD/Function?Aid=1&Bid=2&Cid=3
ViewD shows another list based on Selections from ViewA, ViewB, and ViewC, Then the user Selects again.
At this point I would like to POST Aid, Bid, Cid, and Did and save them in my database. Ideally the user would click the link, the data would be posted and then the site would redirect the user back to the homepage. Should I create another model and controller to Handle the post? I thought about trying to do the POST from controllerD but that doesn't seem like the proper way to do this.
The msdn tutorials only show posting directly from a view with a strongly typed model. I kinda stuck and I would prefer not to make this a complete mess.
Edit for Code
Controller
public ActionResult myFunction(int Aid = 0, int Bid, int Cid)
{
//query D stuff here
if (D == null)
{
return HttpNotFound();
}
return View(D.ToList());
}
[HttpPost]
[InitializeSimpleMembership]
public ActionResult CreateQuote(int Aid, int Bid, int Cid, int Did)
{
Quote myQuote = new Quote();
myQuote.Customer_ID_FK = (int)Membership.GetUser().ProviderUserKey;
myQuote.A_ID_FK = Aid;
myQuote.B_ID_FK = Bid;
myQuote.C_ID_FK = Cid;
myQuote.D_ID_FK = Did;
if (ModelState.IsValid)
{
db.Quotes.Add(myQuote);
db.SaveChanges();
db.Quotes.Max();
int mymax = db.Quotes.Max(q => q.ID);
return RedirectToAction();
}
return View(D.ToList());
}
[HttpPost]
[InitializeSimpleMembership]
public ActionResult CreateQuote(Quote myQuote)
{
myQuote.Customer_ID_FK = (int)Membership.GetUser().ProviderUserKey;
if (ModelState.IsValid)
{
db.Quotes.Max();
int mymax = db.Quotes.Max(q => q.ID);
db.Quotes.Add(myQuote);
db.SaveChanges();
return RedirectToAction();
}
return View(D.ToList());
}
It usually makes sense to put your post handler in the controller it's related to. This isn't always the case, as sometimes it would make more sense to make a new controller to handle all posts related to a certain task. You should also understand the distinction between a method IN a controller, and a controller. A controller is just a class that inherits from System.Web.Mvc.Controller and can have methods just like any other class. A perfectly reasonable controller could look like this:
public class DController : Controller
{
//GET /d
public ActionResult Index()
{
//MyModel is a class that would contain the logic to display
//the selections from A, B, and C
var model = new MyModel();
return View(model);
}
//POST /d/saveresults
//We only want this method to accept POST
[HttpPost]
public ActionResult SaveResults(MyEntity data)
{
var model = new MyModel();
model.SaveResultsToDatabase(data);
return Redirect("/");
}
}
The important thing in a controller is to keep logical processing to a minimum. There's nothing wrong with having an if statement here and there, but the majority of your logic should be handled by your model. A controller is there primarily to pass data between your views and models.

Categories