Requesting features for AutoMapper

On the AutoMapper mailing list, I get a lot of what I consider wacky requests.  Not because the requests aren’t valid, but rarely do I get any context of what people are trying to do with AutoMapper.  As a reference, we are using AutoMapper in these situations:

  • Mapping from Domain/Presentation Model to ViewModel
  • Mapping from Domain/Presentation Model to EditModel (forms) <- yes, different concerns at play here
  • Mapping from Domain to a Reporting model (think printable view screens, not analytics)
  • Mapping from EditModel forms to Command objects

Some of the requests I’ve inferred include a lot of mapping from ViewModels back to Domain models.  Personally, this seems wacky to me, unless you’re in some sort of ActiveRecord/CRUD scenario.  In those cases, I’d rather expose my model directly to my views.

If AutoMapper doesn’t do what you want, a few things might be true:

  • There is a bug
  • You’re doing something valid, but in a scenario I haven’t encountered
  • You’re doing something you shouldn’t do, and trying to attach two boards with a screw and a hammer

Object-to-object mapping is a broad spectrum of distinct scenarios, and AutoMapper really only focuses on the scenarios where your destination type looks like your source type, plus some flattening.  So if you’d like a scenario to be supported by AutoMapper, two things would greatly help me:

  • Code showing a failing test
  • Description of the context for which you’re trying to use it

Context is very helpful for me in the overall design, as only failing tests show me contrived, Foo to FooDto scenarios.  It helps if I understand at what place in your architecture you’re trying to use it, as it may not line up to how it was originally designed.  But context tells me if there is a broader concept at play, and I can design (or not) for that category of usage.

Thanks again to everyone that has contributed, I’ve been consistently surprised by the number of feature requests that include a patch.  To date, I’ve received around 25 patches from the community, far exceeding any expectations I had.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in AutoMapper. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Betty

    We’re currently looking at using Automapper as part of a on going data migration tool where we pull from one or more source convert the data using automapper then dump it into a new database.

    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.

  • @Betty

    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.

  • mendicant

    Jimmy, if it’s not too much trouble, could you give me a quick (very high level) rundown on how your command object works? When I read that it suddenly dawned on me that it might make a ton more sense to use the command pattern than our current solution when updating the domain from an edit model.

    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?

  • Eyston

    While mapping from DTO back to Entity isn’t a good idea (the Entity should be more complex then a DTO), it is an area that seems sort of hard to me. I haven’t looked at Command objects (I’m a pattern noob) but anything to help with taking an stupid Edit Model and initiating behavior on the Entity is useful to me :)

    Time to google on Command~

  • @mendicant and @Eyston

    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 :P

  • Anthony

    Automapper looks great. I’m yet to use it but I think it will work really well in the scenario I have.

    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).