views:

434

answers:

2

I have a site where I'm using fluentNhibernate and Asp.net MVC. I have an Edit view that allows user to edit 8 of the 10 properties for that record (object). When you submit the form and the Model binds, the two un-editable fields come back in the view-model as Empty strings or as default DateTime values depending on the type of property.

Because I'm also using AutoMapper to map my view-model to my Domain Entity, I cannot just load a fresh copy of my object from the database and manually set the 2 missing properties. Whats the best way to persist those fields that I don't want edited?

One way that does work is to persist the values in hidden Input fields on my View. That works but feels gross. I appreciate any recommendations. Is there a way in my AutoMapper to configure this desired functionality?

UPDATE: Ok, So I guess I'm not trying to ignore the fields, I'm trying to make sure that I don't persist null or empty string values. Ignoring the fields in AutoMapper does just that, they get ignored and are null when I attempt to map them before Saved to my repository.

+2  A: 

You can tell Automapper to ignore the 2 properties:

Mapper.CreateMap<Source, Destination>()
.ForMember(dest => dest.SomeValuefff, opt => opt.Ignore());

Possible related question.

mxmissile
I've tried this, I just get null values instead of empty strings and the DateTime properties come back with default values.
shanabus
Well, I take that back - your solution does work if I load the object from the repository before mapping. This way the ignored fields won't overwrite the freshly loaded object - only the fields that I want to be updated will be. Thanks
shanabus
Sorry, i rejected this answer because as i mention in my first comment, Ignore() causes the property to be 'newed' up. That is, Ignoring a DateTime property sets it to something like '01/01/0001' and Ignoring a string property sets it to "", not null.
shanabus
+2  A: 

The asp.net mvc DefaultModelBinder is extensible, and you can override it to create your own binding schema. But this will involve more work than two "hidden Input fields", which , in my point of view, is not that gross.

J.W.
I think the hidden input fields is gross. Besides the fact that you're sending data to the client just so that it can be sent back, it can also be modified. I use non-editable fields for things like ownership, creation date, etc.
James S
JW, its not that 2 hidden input fields are gross - but the next view I'll be working with will contain more like 10 hidden input fields. Thats when I started questioning this method. This is an internal application but James S has a good point too - these fields can be tampered with.
shanabus
While I am hesitant to believe this is the best solution, it is the solution that I will be using.
shanabus