Another option here is simply don't include this attribute in your view and it won't be bound. Yes - you are still open to model injection then if someone creates it on the page but it is another alternative. The default templates in MVC will create your EditorFor, etc as separate items so you can just remove them.
This prevents you from using a single line view editor with EditorForModel, but the templates don't generate it that way for you anyways.
Up vote 1 down vote favorite share g+ share fb share tw.
I have a view model sent to the edit action of my controller. The ViewModel contains references to EntityObjects. (yea i'm fine with it and don't need to want to duplicate all the entities properties in the viewmodel).
I instantiate the view model and then call UpdateModel. I get an error that a property is "null" which is fine since it is a related model. I am trying to exclude the property from being bound during model binding.
On debugging it I see in the entity where the model binder is trying to set the value of the property to null. Here is my edit action: var model = new SimplifiedCompanyViewModel(id); var excludeProperties = new string { "Entity. RetainedEarningsAccount.
AccountNo" ,"Property. DiscountEarnedAccount. ExpenseCodeValue" ,"Entity.EntityAlternate.
EntityID" ,"Property.BankAccount. BankAccountID" ,"Entity. PLSummaryAccount.
AccountNo" ,"Property.RefundBank. BankAccountID" ,"Company.Transmitter. TCC" }; try { UpdateModel(model, String.
Empty, null, excludeProperties); if (ModelState. IsValid) { //db.SaveChanges(); } return RedirectToAction("Index"); } catch { return View(model); } I have looked at a few other issues about specifying a "prefix" but I don't think that is the issue since I am telling it to bind to the viewmodel instance not just the entity object. Am I excluding the properties correctly?
Strange thing is is only seems to happen on this item. I suspect it may be an issue with the fact that there is actually no refund bank related to my entity. But I have other related items that don't exist and don't see the same issue.
More info... since I'm told me model isn't designed well. The Company is related to a BankAccount. The Company view shows the currently related BankAccount.
BankAccountId and there is a hidden field with the BankAccount.Key. I use jQueryUI autocomplete feature to provide a dropdown of bank account displaying the BankAccount. BankAccountId and when one is selected the jQuery code changes the hidden field to have the correct Key value.
So, when this is posted I don't want the current bankaccounts BankAccountID modified, hence I want it to skip binding that field. If I exclude BankAccountId in the model then on the BankAccount edit view the user would never be able to change the BankAccountId since it won't be bound. I'm not sure how this indicates a poor model design.
Asp.net-mvc-3 model-binding link|improve this question edited Dec 2 '11 at 18:48 asked Nov 30 '11 at 20:35PilotBob674514 80% accept rate.
1 you might be fine with it, but you are opening yourself up to potential troubles down the road. What if new values are added to your entity that you don't account for down the road. Lets say you add a field named 'DiscountRate' (hypothetically) and the end user sees it used somewhere else, They can include this value on the form and inject your model.
Theres lots of other reasons to use ViewModels as well. Duplicating properties is generally a simple copy/paste/cleanup and its NOT applicable to the DRY principle here. – Adam Tuliper Nov 30 '11 at 21:21 Well, you hit the nail on the head.
It doesn't seem very dry to me. – PilotBob Nov 30 '11 at 21:51 DRY generally applies to logic, not to view models. One view = one view model.
Use automapper to easily map between them. Jimmy Bogard has a great attribute for this that makes it almost automatic - ie you create the view model, load up your Customer entity for example, and return it in the action method. The AutpMap attribute will then convert it to a ViewModel.
See lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models – Adam Tuliper Dec 1 '11 at 6:26 If the ViewModel is the same as the Model it seems not DRY to me. However this is such a complex view which uses several related entities I may have to resort to doing this. I'm just not sure how well automapper or something will handle all the relationships and I will probably have to manually code all of the update code.
I'll look at the article you've listed above. – PilotBob Dec 2 '11 at 18:50 true, if its manual then you don't have to worry about the bankaccount.name being bound back then. – Adam Tuliper Dec 3 '11 at 2:10.
Another option here is simply don't include this attribute in your view and it won't be bound. Yes - you are still open to model injection then if someone creates it on the page but it is another alternative. The default templates in MVC will create your EditorFor, etc as separate items so you can just remove them.
This prevents you from using a single line view editor with EditorForModel, but the templates don't generate it that way for you anyways. EDIT (adding above comment) DRY generally applies to logic, not to view models. One view = one view model.
Use automapper to easily map between them. Jimmy Bogard has a great attribute for this that makes it almost automatic - ie you create the view model, load up your Customer entity for example, and return it in the action method. The AutpMap attribute will then convert it to a ViewModel.
It's not that easy. The view is a display of Company that displays the BankAccount related to that entity. When they change the BankAccount I have a hidden field that gets populated with PK value.
But, the BankAccount.Name" rel="nofollow">BankAccount.Name is still posted with the form. I don't want the BankAccount.Name" rel="nofollow">BankAccount.Name to be changed, I want the relation to change. – PilotBob Dec 2 '11 at 18:41.
Use the Exclude property of the Bind attribute: Bind(Exclude="Id,SomeOtherProperty") public class SimplifiedCompanyViewModel { public int Id { get; set; } // ... } This is part of the System.Web. Mvc namespace. It takes a comma-separated list of property names to exclude when binding.
Also you should consider using TryUpdateModel instead of UpdateModel. You can also just have the default model binder figure it out by passing it as an argument to the constructor: public ActionResult Create(Bind(Exclude="Id")SimplifiedCompanyViewModel model) { // ... }.
Try the Exclude attribute. I admit that I haven't ever used it. Exclude public Entity Name {get; set;}.
Hmm.. I don't want it excluded from binding when I am actually editing the Bank record. But, when editing the parent Company record I want the BankAccountId (which is actually the business key) excluded since I am actually modifying which entity is related by modifying in the FK value. – PilotBob Nov 30 '11 at 21:54 @PilotBob more evidence that you really need to design your models a little better.
– Dismissile Dec 1 '11 at 16:54 @Dismissile The difference is when modifying an Entity that is related to a BankAccount vs modifying the BankAccount entity itself. Its not about the model. We don't all work on Demoware with simple 3 entity models.
– PilotBob Dec 2 '11 at 18:38.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.