I want to configure my model binders with Nhibernate:
So I have:
<object id="GigModelBinder" type="App.ModelBinders.GigModelBinder, App.Web" singleton="false" >
<property name="VenueManager" ref="VenueManager"/>
<property name="ArtistManager" ref="ArtistManager"/>
I have an attribute which marks controller actions so that they use the correct model binder i.e.
[AcceptVerbs("POST")]
public ActionResult Create([GigBinderAttribute]Gig gig)
{
GigManager.Save(gig);
return View();
}
This works fine and my GigModelBinder has the correct VenueManger and ArtistManager injected
However if in application Start I add:
System.Web.Mvc.ModelBinders.Binders.Add(typeof(App.Shared.DO.Gig), new GigModelBinder());
and in a controller action use :
UpdateModel<Gig>(gig);
for example:
[AcceptVerbs("POST")]
public ActionResult Update(Guid id, FormCollection formCollection)
{
Gig gig = GigManager.GetByID(id);
UpdateModel<Gig>(gig);
GigManager.Save(gig);
return View();
}
The VenueManger and ArtistManager has NOT been injected into the GigModelBinder.
Any ideas what I'm doing wrong?
In the first example you go via Spring.NET to retrieve your object. That means it'll look for all the dependencies and stick them into your object and all works well.
In the second example you forget about Spring.NET all along and just create an ordinary instance of a class.
The line where you register your binder should look like this:
System.Web.Mvc.ModelBinders.Binders[typeof(App.Shared.DO.Gig)] = context.GetObject("GigModelBinder");
where context is either an IApplicationContext or a IObjectFactory instance from Spring.NET package.
Best regards,
Matthias.
Related
I have a web-API project and a simple class with a few properties, some are marked <JsonIgnore>.
In my MVC-controller I put Return Json(instanceOfMyClass, JsonRequestBehavior.AllowGet). All members are serialized.
I put Return Json(Of MyClass)(instanceOfMyClass) in my WEBAPI-controller. Only the members I intend to serialize are present.
How can I ignore these properties independent of the controller that's going to serialize.
The JsonResult in MVC does not actually use JSON.NET which is why [JsonIgnore] is not working. Instead it uses the JavaScriptSerializer class.
To make the JavaScriptSerializer skip a property, you can you the [ScriptIgnore] attribute on your model property.
An alternative would be to make a custom ActionResult that uses JSON.NET's JsonConvert to serialize the object which would then honor the [JsonIgnore] attribute.
In case it helps anyone, it didn't seem possible or straightforward to use [ScriptIgnore] in my .net Core app, so I did this:
public IActionResult Index()
{
Response.ContentType = "text/json";
return Content(JsonConvert.SerializeObject(instanceOfMyClass));
}
If you're using the Html.TextBoxFor() type methods, you may well end up with Form controls that have dots in their names, like this:
<input type="text" name="Contact.FirstName" id="Contact_FirstName" />
If you want MVC to map those named fields to parameters in your controller (as opposed to an object parameter or whatever), you have to get the parameter names right. What to do about the dots?
Neither this:
[HttpPost]
public ActionResult FooAction(string firstName)
not this:
[HttpPost]
public ActionResult FooAction(string contact_FirstName)
seem to work.
Edit: Having a suitable object parameter would work (eg see clicktricity's answer), but I'm looking for a way to do it with named value parameters.
I have found another way, a kind of hack because I believe this is misuse of BindAttribute, to associate firstName parameter with Contact.FirstName input element:
[HttpPost]
public ActionResult FooAction([Bind(Prefix="Contact.FirstName")]string firstName)
This for sure works with ASP.NET MVC 1.
Depending on the other form controls, you should be able to have the MVC default model binder construct a Contact object for you. Then the signature of your action method would be:
[HttpPost]
public ActionResult FooAction(Contact contact)
Then the Contact.FirstName (and any other fileds) will be bound correctly
As Clicktricity suggests in comments you may use
[HttpPost]
public ActionResult FooAction(FormCollection form)
{
firstName = form["Contact.FirstName"];
}
Suppose I want to allow to select our entity (from a dropdown, etc) on a page, let's say Product. As a result I may receive this:
public ActionResult SelectedAction(Guid productId)
{
}
But, I want to use model binders power, so instead I write model binder to get my product from repository and instead use
public ActionResult SelectedAction(Product product)
{
if (ModelState.IsValid) {} else {}
}
My model binder will set model state to false if product is invalid.
Now, there're problems with this approach:
It's not always easy to use strongly-typed methods like Html.ActionLink(c => c.SelectedAction(id)) since we need to pass Product, not id.
It's not good to use entities as controller parameters, anyway.
If model state is invalid, and I want to redirect back and show error, I can't preserve selected product! Because bound product is not set and my id is not there. I'd like to do RedirectToAction(c => c.Redisplay(product)) but of course this is not possible.
Now, seems like I'm back to use "Guid productId" as parameter... However, there's one solution that I'd like to present and discuss.
public class EntityViewModel<T> where T : BaseEntity
{
public EntityViewModel(Guid id)
{
this.Id = id;
}
public static implicit operator EntityViewModel<T>(T entity)
{
return new EntityViewModel<T>(entity.Id);
}
public override string ToString()
{
return Id.ToString();
}
public Guid Id { get; set; }
public T Instance { get; set; }
}
Now, if I use
public ActionResult SelectedAction(EntityViewModel<Product> product)
{
if (ModelState.IsValid) {} else {}
}
all the problems are solved:
I can pass EntityViewModel with only Id set if I have only Id.
I don't use entity as parameter. Moreover, I
can use EntityViewModel as property inside another ViewModel.
I can pass EntityViewModel back to RedirectToController and it will keep its Id value, which will be
redisplayed to user along with the validation messages (thanks to MVCContrib and ModelStateToTempData / PassParametersDuringRedirect).
The model binder will get Instance from the repository and will set model state errors like "Not found in database" and so on. And I can use things like ActionLink(c => c.Action(Model.MyProductViewModelProperty)).
The question is, are there any drawbacks here? I can't see anything bad but I'm still new to MVC and may miss some important things. Maybe there're better and approved ways? Maybe this is why everybody uses entity IDs as input parameters and properties?
Overall that looks like a good appoach to me...
As an alternative, you could use POCO for your viewmodel then I think all 3 problems would be solved automatically. Have you seen the Automapper project that allows an Entity to DTO approach? This would give you more flexibility by separating you ViewModel from your EntityModel, but really depends on the complexity of you application you are building.
MVC's ViewDataExtensions might also be useful instead of creating custom containers to hold various viewmodel objects as you mention in number 2.
MVCContrib's ModelStateToTempData should work for any serializable object (must be serializable for any out of process sessionstate providers eg. SQL, Velocity etc.), so you could use that even without wrapping your entity classes couldn't you?
Currently I'm passing my domain objects to my views, and binding directly to them from POSTs. Everyone says this is bad, so I'm attempting to add in the ViewModel concept.
However, I can't find a way to do this very elegantly, and I'd like to know what other people's solutions are to not ending up with a very messy controller action.
the typical process for say some "add person" functionality looks like this:
make a GET request for a view representing a blank Person viewmodel
post back (in)valid data
controller binds posted data onto a person viewmodel
if binding fails, i need to do the same action as in (1) but with some data, not a blank object and errors
if the binding suceeded, i need to map the properties from the VM onto a real model
validate the model
if validation passed: save the person, commit, map the users details to a display VM and return it in a view
if validation failed, do the same actions as in (1) but with some data and errors
Doing all this in a controller action (ignoring the GET) certainly isnt SRP or DRY.
Im trying to think of a way of breaking this process up so that it does abide by SRP, is clean, modular and above all testable.
What are peoples solution to this?
I've been experimenting with custom controller-action-invokers to separate the concerns up into individual methods, smart modelbinders and just plain brute force but i havent yet come across a solution in happy with.
P.S. as it adds so much complexity, convince me why i even need to bother
I've felt the same discomfort. My only way around it has been to do the following:
Create a binder to bind and validate the view model
Create a binder to get the entity from the database (or just do this in the controller)
Call an inherited Save method in the superclass. This method takes the viewmodel and the entity that will be updated, and does all the work you listed in your steps.
The action method looks like this:
public ActionResult Whatever(TViewModel viewModel, TEntity entity)
{
return Save(viewModel, entity);
}
The base controller has a generic definition, like so:
public abstract BaseController<TEntity, TViewModel>
where TEntity : Entity
where TViewModel : ViewModel
The constructor has two dependencies, one for the entity repository and another for the model mapper, like so:
protected BaseController(IRepository<TEntity> repository, IMapper<TEntity, TViewModel> mapper)
With this in place, you can then write a protected Save method that can be called from the controller actions in the subclass, like so:
protected ActionResult Save(TViewModel viewModel, TEntity entity)
{
if (!ModelState.IsValid)
return View(viewModel);
_mapper.Map(viewModel, entity);
if (!entity.IsValid)
{
// add errors to model state
return View(viewModel);
}
try
{
_repository.Save(entity);
// either redirect with static url or add virtual method for defining redirect in subclass.
}
catch (Exception)
{
// do something here with the exception
return View(viewModel);
}
}
As far as testability, you can test the save method passing in valid/invalid view models and entities. You can test the implementation of the model mapper, the valid state of the view model, and the valid state of the entity separately.
By making the base controller generic, you can repeat this pattern for each entity/viewmodel combo in your domain, if you're creating many controllers to do the same thing.
I'm very interested to hear what others have to say about this. Great question.
The MVVM (ViewModel) pattern is definitely the one to go for, I had a similar question about POSTing back to an action a few days back - here is the link: MVVM and ModelBinders in the ASP.NET MVC Framework
The result was that you can use the Bind attribute to post back the complex type you want.
I have many good solutions in the asp.net mvc sample application which is in the download of valueinjecter (mapper that I use to map ViewModels to/from Entities, you can also map FormCollection/Request to Entities)
here's one:
public class TinyController :Controller
{
private readonly IModelBuilder<Person, PersonViewModel> modelBuilder;
public TinyController()
{
modelBuilder = new PersonModelBuilder();
}
public ActionResult Index()
{
return View(modelBuilder.BuildModel(new PersonRepository().Get()));
}
[HttpPost]
public ActionResult Index(PersonViewModel model)
{
if (!ModelState.IsValid)
return View(modelBuilder.RebuildModel(model));
var entity = modelBuilder.BuildEntity(model);
...
//save it or whatever
}
}
I'm wondering if there is a good example of how to edit ASP.NET Profile settings in MVC using model binding.
Currently I have:
a custom ProfileCommon class derived from ProfileBase.
a strongly typed view (of type ProfileCommon)
get and post actions on the controller that work with ProfileCommon and the associated view. (see code below).
Viewing the profile details works - the form appears all the fields are correctly populated.
Saving the form however gives exception:System.Configuration.SettingsPropertyNotFoundException: The settings property 'FullName' was not found.
Thinking about this it makes sense because the model binding will be instantiating the ProfileCommon class itself instead of grabbing the one of the httpcontext. Also the save is probably redundant as I think the profile saves itself automatically when modified - an in the case, probably even if validation fails. Right?
Anyway, my current thought is that I probably need to create a separate Profile class for the model binding, but it seems a little redundant when I already have a very similar class.
Is there a good example for this around somewhere?
[AcceptVerbs(HttpVerbs.Get)]
public ActionResult Edit()
{
return View(HttpContext.Profile);
}
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Edit(ProfileCommon p)
{
if (ModelState.IsValid)
{
p.Save();
return RedirectToAction("Index", "Home");
}
else
{
return View(p);
}
}
It sounds correct when you say that the ProfileCommon instance is created from scratch (not from the HttpContext) in the post scenario - that's what the DefaultModelBinder does: it creates a new instance of the type based on its default constructor.
I think you could solve this issue by creating a custom IModelBinder that goes something like this:
public class ProfileBinder : IModelBinder
{
public object BindModel(ControllerContext controllerContext,
ModelBindingContext bindingContext)
{
return controllerContext.HttpContext.Profile;
}
}
You may need to do some casting to make it fit your profile class.
To use this ProfileBinder, you could then add it to your Edit controller action like this:
public ActionResult Edit([ModelBinder(typeof(ProfileBinder))] ProfileCommon p)