views:

100

answers:

3

After reading ASP.NET MVC 2 in Action and watching Jimmy Bogard's presentation from MvcConf (both highly recommended!), I began to implement some of their ideas.

One of the cool things they do, is not only to use AutoMapper to map your entities to some viewmodel, but automate this with an AutoMapViewResult:

public class EventsController : BaseController
{
    public ActionResult Show(Event id) // EntityModelBinder gets Event from repository
    {
        return AutoMapView<EventsShowModel>(id); // AutoMapView<T>(model) is a helper method on the BaseController, that calls AutoMapViewResult<T>(...)
    }
}

// not exactly what you'll find in the book, but it also works :-)
public class AutoMapViewResult<TDestination> : ViewResult
{
    public AutoMapViewResult(string viewName, string masterName, object model)
    {
        ViewName = viewName;
        MasterName = masterName;

        ViewData.Model = Mapper.Map(model, model.GetType(), typeof(TDestination));
    }
}

This all works great, but now there's a Edit action with its EventsEditModel:

public class EventsEditModel
{
    // ... some properties ...
    public int LocationId { get; set; }
    public IList<SelectListItem> Locations { get; set; }
}

public class EventsController : BaseController
{
    public ActionResult Edit(Event id)
    {
        return AutoMapView<EventsEditModel>(id); 
    }
}

And now (finally) the question:

What do you think, is the best way to get the locations from some sort of data source such as a repository to the EventsEditModel's Locations property?

Keep in mind, that I want to use the AutoMapViewResult and a lot of different entity-viewmodel combinations.

Update:

I went with Necros' idea and created a custom attribute. You can look at the code and download it on my blog ASP.NET MVC: Loading data for select lists into edit model using attributes.

A: 

Well, add a constructor with a parameter and a property into your controller and use DI (personally I like Ninject) to inject the correct repository implementation:

public IEventsRepository _repo;

public EventsController(IEventsRepository repository)
{
  _repo = repository;
}

Wire (bind) the dependencies up in the global.asax.cs in Ninject application and site module (if you need expanded answer with that included, please let me know),

then in your Edit action use the repository to get the Locations. Suppose you have the LoadLocations() method on your repository interface and concrete implementation of it in, for instance, SqlEventsRepository (implements IEventsRepository), you do it simply by calling the method:

public ActionResult Edit(Event id)
{
...
EventsEditModel model = new EventsEditModel();
_repo.GetInstance(id);
model.Locations = _repo.LoadLocations();
...
}

I am making this up because you have not provided too much information. And I don't know Automapper specifics when you want to load some additional data from the datastore prior to mapping the Entity to the ViewModel.

Also you don't specify whether this Edit action is GET or POST, but I assume it is GET. Assuming that it's really GET, I don't know how can you load anything by providing the Entity to the action.

Most commonly the GET methods use parameters of type string or int (most likely those are slugs or ids of somekind) and POST methos use parameters of type ViewModel (not Entity).

So you POST method signature should be like this

[HttpPost]
public ActionResult Edit(EventsEditModel model)...

I used to use Entities directly in my action signatures and was failing all the time, so I discourage it to others now.

HTH

mare
Clearly you didn't watch Jimmy Bogard's talk mentioned in the question. Your answer is totally off-topic.
Necros
+1  A: 

I haven't gotten to the point (since I saw the talk) when I needed this, but I have a possible solution for this in mind. I think it would work to create an attribute, specifying that this property needs to be loaded. I would start with an abstract class:

public abstract class LoadDataAttribute : Attribute
{
    public Type Type { get; set; }

    protected LoadDataAttribute(Type type)
    {
        Type = type;
    }

    public abstract object LoadData();
}

Then create specific version for each type you want to load (Locations in your case)

public class LoadLocationsAttribute : LoadDataAttribute
{
    public LoadLocationsAttribute() : base(typeof(IList<SelectListItem>))

    public override object LoadData()
    {
        // get locations and return IList<SelectListItem>
    }
}

In your ExecuteResult of AutoMappViewResult you would find all properties with LoadDataAttribute, call LoadData(), cast it to type specified in the attribute and assign it to the property.

I case you just want to load select lists this way, you can just return IList<SelectListItem> instead of object, and save yourself some trouble with casting.

Your view model would the obviously use the attribute.

public class EventsEditModel
{
    // ... some properties ...
    public int LocationId { get; set; }

    [LoadLocations]
    public IList<SelectListItem> Locations { get; set; }
}
Necros
Collections in view model classes (and actually other properties too) should be populated from service classes not from some standalone attributes classes. Going your way, in a few weeks of working on an app you would end up with dozens of attribute classes. I've seen Bogard's videos and his articles and it's all about Automapper. Sometimes he's bending the app to fit in his use cases of Automapper. As @Omu said, his solution using ValueInjector is much easier and natural to the application.
mare
@Necros: Interesting approach, I'll definitely take a closer look at that. As @mare says, one drawback could be that you end up with a lot of Attributes. Maybe there's a more generic solution, something like `[LoadSelectListData(DataType=typeof(Location), TextProperty="Name", ValueProperty="Id")]`...
Dave
@mare: I had a look at @Omu's ValueInjecter sample application and sure enough it's a clean solution. But instead of writing a bunch of attributes, you end up writing the same amount of ModelBuilders...
Dave
@mare Well the way Jimmy shows it, you are calling your service layer from different places, like ActionResults and FormHandlers, so I figured calling it from attributes won't be that big of a deal considering. The value injecter solution uses same amount of injections instead of attributes. This is just the general idea, im sure a lot can be abstracted away, and it can be made more generic.
Necros
I wrote a custom attribute for loading data for select lists. It is relatively flexible, so I can use it for every entity and set the selected value either to the another property's value of the same edit model or a fixed value. So I end up with just one attribute for all my select lists. I think that's pretty good solution.
Dave
@Dave - update your question with the final solution if it's not too much trouble. I'm interested to see how it turned out.
Necros
@Necros: just updated the question, had to write a blog post first ;-)
Dave
+1  A: 

I would recommend you to look at the asp.net-mvc sample application from here which does this much much simpler than automaper

Especially look at the TinyController

Omu
I had a look at your sample application and as far as I can tell now, it looks like a good solution. Since I asked this question for a project I'm working on quite some time and already set up the AutoMapper stuff, I don't want to switch to a different solution. But I'll definitely keep that in mind for a next project.
Dave
I've worked on a project with automapper as well, but we were using it just for mapping entities into rowModels (for tables/lists), mainly for displaying stuff, but for forms I've created the ValueInjecter because with automapper there is just to much configuration that you have to do, as with my approach I was using one implemenatation of IBuilder<Entity,ViewModel> for multiple forms for editing/creating stuff because ValueInjecter doesn't care about types, he maps properties
Omu