Currently, we have a very large investment in Datasets. In more recent times this is proving to be difficult as we are finding that we need the light weight nature of a DTO to achieve what has become know as view models. Typically we are using them in the scenarios you have described (i.e. summary section at the top of a page to provide context) but also in many of our ajax scenarios.

In these cases, trying to serialize a dataset to the browser when we want to work with json objects that have more of any object structure (i.e. { item : ”, other : { hello : ‘what’, world : ‘oh ok’ } } ) is rather tedious. The same also works in reverse, when we get jquery to send the server a json object, .net can handle the deserialisation just fine, but then there is the question of persistence. We don’t use the datasets datatable to generate the sql to conduct the update, we use tableadapters with queries hocked up to stored procs to handle the update. Hence we have 2 options, when going from the UI to the BL to the DL to the dataset. We can either pass a dto (but this would be a different dto to the view model dto’s as the view model dto’s are UI specific) or create methods with that have a param for each property we want to update.

Hence where we are looking to use automapper, is to go from the dataset to the view model dto and in situations where we have a domain model being passed from the UI through to the DL, to map the data from the view model dto to the domain model dto.

I guess 2 things I was wondering from this, 1) would you say our use is valid and 2) does Automapper support datasets 3) Automapper can go from a object hierarchy to a flatter structure, can one go from a flat dataset structure to an object heyracky (for situation where the dataset has three fields ‘item’, ‘hello’ & ‘what’ and we want the json format to be { item : ”, other : { hello : ‘what’, world : ‘oh ok’ } or what ever – note this structure is needed for some complex ajax scenarios that we have where we request the full json object to start with, then we update just parts of the object from the server – i.e. request for an updated ‘other’ from the server).

Cheers
Anthony

It’s on the blog post back log to talk about those kinds of things, and also what context we have that led us to that solution. Hopefully I’ll get to it, eventually

Time to google on Command~

Off the top of my head, I would expect it to know how to take the edit model and update a corresponding domain model, but then to me that just seems like writing a reverse mapping. Am I off here?

Yeah, AutoMapper only really shines when the source/destination type look very similar. This is true in many cases where the destination type is modeled from the source type. If that’s not the case, you’ll likely have a lot of mismatches.

The current plan is to map from/to: Entity Framework, Generic Rest Data Service that returns xml, MySql and xml deserialized from the harddrive.

Not convinced it’s the best route to take yet as the code seems like it would be easier to write myself due to not many columns lining up and the Entity Framework being annoying with duplicate keys etc.