ASP.NET MVC model to viewmodel mapping with additional secondary entities

Question

I'm using ASP.NET MVC 3, with Raven DB as a backing data store. I have a set of models, which I'm interested in transforming into ViewModels. To accomplish this, I'm leveraging AutoMapper to take care of the dirty work of mapping each property to the corresponding one in the ViewModel. Let's say that I've got a model like so:

public class FooModel
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int AlphaId { get; set; }
    public int BetaId { get; set; }
}

And then let's say I want to transform it into a ViewModel like so:

public class FooViewModel
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int AlphaId { get; set; }
    public Alpha Alpha { get; set; }
    public int BetaId { get; set; }
    public Beta Beta { get; set; }
}

My map is then set up like this at app startup:

Mapper.CreateMap<Foo, FooViewModel>();

Then, in the controller I'm performing the map as so:

public ActionResult FooDetails(string id)
{
    using(var session = this.documentStore.OpenSession())
    {
        var fooInstance = session.Load<Foo>(id);
        var fooViewModel = Mapper.Map<FooViewModel>(fooInstance);
        return this.View(fooViewModel);
    }
}

The problem is that as you can see above, the entity coming out of the repository has 2 properties which are the keys of other objects, of types Alpha and Beta. I'm interested in hydrating Alpha and Beta based upon the AlphaId and BetaId keys.

At first I thought I'd leverage AutoMapper's custom conversion capabilities, but I don't think that will work given that we would need a data session to be injected into the mapping (to call the data store to retrieve the Alpha or Beta object).

The other option is to just do all the work in the controller action, but that quickly gets unwieldy (not in the particular example given, but thats just an example to illustrate the point).

Where should the hydration of Alpha and Beta take place, and what's a good pattern here?

Answer 1

It perhaps isn't ideal, but could you not just create maps for the two references and map them after the fact. You still have to call them seperately, but you're letting AutoMapper do the heavy mapping, rather than filling your controller with your own maps.

public ActionResult FooDetails(string id)
{
    using(var session = this.documentStore.OpenSession())
    {
        var foo = session.Load<Foo>(id).Include(....);
        var alpha = session.Load<Alpha>(foo.AlphaId);
        var beta = session.Load<Beta>(foo.BetaId);

        // null checks

        var fooViewModel = Mapper.Map<FooViewModel>(foo);
        fooViewModel.Alpha = Mapper.Map<AlphaViewModel>(alpha);
        fooViewModel.Beta = Mapper.Map<BetaViewModel>(beta);

        return View(fooViewModel);
    }
}  

I haven't used AutoMapper all that much, but perhaps you can pass in child objects through the Map function (to feed the ForMember chains on CreateMap)? Perhaps Alexandre's AfterMap suggestion might work, but I don't see how you'd hydrate the 'referenced' children without creating the map inside the controller action (but then you may as well just use ForMember and the Raven session directly and have only one Mapper.Map).

Addition - The AutoMapper documentation suggests a similar method for nested/child maps - https://github.com/AutoMapper/AutoMapper/wiki/Nested-mappings. Although it's more akin to an object reference, rather than a object id reference situation.

I can't comment on other answers yet, but with regard to Pavel's answer - you don't really use Raven in that way, there is no o/r mapping (other than the internal JSON -> object) or data access layer, you just use the Raven session directly (perhaps through a service, but there's certainly no need for a repository or similar). With regards to referencing, byte has it right and as he commented on one of the other answers, the best approach is to store an id reference and use a Raven include - it's the same result and still uses only one request.

Answer 2

I agree with the person up there but if you can't expand your model, you always can define the mapping with AfterMap like this:

Mapper.CreateMap<Foo, FooViewModel>()
.AfterMap(MapAlphaBetaFromFooToFooViewModel);


public void MapAlphaBetaFromFooToFooViewModel(Foo foo, FooViewModel fooViewModel)
{
// Here the code for loading and mapping you objects
}

this way, when you'll do the mapping, Automapper will automatically run the method after the basic mapping is done.

Answer 3

One optimization you could do is to load related document at one go from RavenDB and not make separate call to load each related document. See RavenDB documentation here.

I cannot think of any other way to map those entities other than doing it in the controller itself as you have shown.

Answer 4

You should care about your architecture at first place. Loading data from DB is a responsibility of Data Access layer, and it should not know how your UI is organized.

I think, the best approach is the following distribution of responsibilities:

1. Data Access Layer has a POCO-based model where entities have references to each other instead of identifiers. This model is exposed to higher layers (the viewmodel for instance).
2. The DAL has a single method that loads all data that is required for the intended action. In your case it should load both Foo, Alpha, Beta entities. Since this happens in one method of DAL, it can probably do this in a single db query. Although the main trick is that other layers don't care how it works.
3. In your controller you then use AutoMapper to flatten the FooModel object into FooViewModel, which is one of the Automapper features.

The key points are:

1. Only DAL knows how it loads data. If necessary, you modify it as you wish without having to modify the AutoMapper-related code.
2. AutoMapper only maps data from one structure to the other and does not affect the data loading strategy.

That said, I would only modify your FooModel:

public class FooModel
{
  public int Id { get; set; }
  public string Name { get; set; }
  public Alpha Alpha { get; set; }
  public Beta Beta { get; set; }
}

and the code that loads it from DB.

However, you may require your original FooModel-like structure to, for example, define an object-relational mapping to that simple structure. But still it's solely up to the DAL.