Reputation: 1645
If I have a model that looks something like this:
public class LoginModel
{
pulbic List<string> UserNames {get; set; }
public string SelectedUserName {get; set; }
public string Password {get; set; }
}
And I also have a controller with a couple of action methods that look something like this:
public ActionResult Login()
{
LoginModel model = null;
model = new LoginModel();
// Code to populate the UserNames property of the LoginModel instance (model)...
return View(model);
}
[HttpPost()]
public ActionResult Login(LoginModel model)
{
if (ModelState.IsValid == true)
{
return RedirectToAction("SomeOtherAction")
}
else
{
return View(model);
}
}
I will need to re-populate the UserNames property of the model object before passing it to the View method. This is something that I can certainly do but it does feel a bit dirty. That leads me to the question. Is there a better way to handle this?
Upvotes: 0
Views: 60
Reputation: 38394
Usually I have a class for a particular model(and closely related entities) that handles database access and populating view models(although you can add even another layer in so that DB access and mapping to view models is separate, perhaps leveraging a mapping framework). Either way, it would have a method like GetLogins that you could call anywhere that needs a list like that, perhaps even other controllers like Friends page that needs to list login names that someone can request friends from, a contrived example but you get the idea.
Since both your Get and POST methods need to re-display the page(POST in the case of an error), both of them can call GetLogins so that you don't repeat that DB access code in both places.
Upvotes: 0
Reputation: 46
Essentially this depends on what your view is actually doing. Certainly if you render your UserNames collection as a list of hidden form fields Model binding could do this for you upon http post. That said this is how http programming is intended to work. State is not intended to stick around between gets and posts.
Really your choices are to rebuild that list on as you mentioned or render out some hidden fields (I would not recommend that) and have model binding do its thing.
Upvotes: 0
Reputation: 583
As I have come to understand MVC are that you should have a method in the model update the UserNames property. All (and nothing more in this matter) your controller should do is to pass the necessary arguments to this function. In that way, your controller is just passing the information which only it can know to the model where the logic should go.
I don't know any asp.net so I can sadly not provide you with a code example.
Upvotes: 0
Reputation: 1039428
This is something that I can certainly do but it does feel a bit dirty.
It's not dirty. It's how MVC works -> it's stateless. As an alternative you could include the list of usernames as hidden fields into the form so that they get POSTed back to the controller. But this is not an information you could rely upon because the user could modify those values. So if you need to trust those values you'd better query your backend for them.
Upvotes: 1