tags:

views:

447

answers:

1

Suppose I want to allow to select our entity (from a dropdown, etc) on a page, let's say Product. As a result I may receive this:

public ActionResult SelectedAction(Guid productId)
{
}

But, I want to use model binders power, so instead I write model binder to get my product from repository and instead use

public ActionResult SelectedAction(Product product)
{
   if (ModelState.IsValid) {} else {}
}

My model binder will set model state to false if product is invalid. Now, there're problems with this approach:

  1. It's not always easy to use strongly-typed methods like Html.ActionLink(c => c.SelectedAction(id)) since we need to pass Product, not id.
  2. It's not good to use entities as controller parameters, anyway.
  3. If model state is invalid, and I want to redirect back and show error, I can't preserve selected product! Because bound product is not set and my id is not there. I'd like to do RedirectToAction(c => c.Redisplay(product)) but of course this is not possible.

Now, seems like I'm back to use "Guid productId" as parameter... However, there's one solution that I'd like to present and discuss.

   public class EntityViewModel<T> where T : BaseEntity
   {
      public EntityViewModel(Guid id)
      {
         this.Id = id;
      }

      public static implicit operator EntityViewModel<T>(T entity)
      {
         return new EntityViewModel<T>(entity.Id);
      }

      public override string ToString()
      {
         return Id.ToString();
      }

      public Guid Id { get; set; }
      public T Instance { get; set; }
   }

Now, if I use

public ActionResult SelectedAction(EntityViewModel<Product> product)
{
   if (ModelState.IsValid) {} else {}
}

all the problems are solved:

  1. I can pass EntityViewModel with only Id set if I have only Id.
  2. I don't use entity as parameter. Moreover, I can use EntityViewModel as property inside another ViewModel.
  3. I can pass EntityViewModel back to RedirectToController and it will keep its Id value, which will be redisplayed to user along with the validation messages (thanks to MVCContrib and ModelStateToTempData / PassParametersDuringRedirect).

The model binder will get Instance from the repository and will set model state errors like "Not found in database" and so on. And I can use things like ActionLink(c => c.Action(Model.MyProductViewModelProperty)).

The question is, are there any drawbacks here? I can't see anything bad but I'm still new to MVC and may miss some important things. Maybe there're better and approved ways? Maybe this is why everybody uses entity IDs as input parameters and properties?

+1  A: 

Overall that looks like a good appoach to me...

As an alternative, you could use POCO for your viewmodel then I think all 3 problems would be solved automatically. Have you seen the Automapper project that allows an Entity to DTO approach? This would give you more flexibility by separating you ViewModel from your EntityModel, but really depends on the complexity of you application you are building.

MVC's ViewDataExtensions might also be useful instead of creating custom containers to hold various viewmodel objects as you mention in number 2.

MVCContrib's ModelStateToTempData should work for any serializable object (must be serializable for any out of process sessionstate providers eg. SQL, Velocity etc.), so you could use that even without wrapping your entity classes couldn't you?

MVC-dot-net
My entities are POCO. The problem for 1) is that business rules don't always allow new Entity(id) so that Id is constructed by ActionLink, and for 3) if entered/selected id is invalid (not in db), I'll get null for entity from repository, and thus null is what will be passed via ModelStateToTempData. So I don't see how AutoMapper can help if you don't have both Id and Entity in your DTO. Remember, the goal is to have entity already retrieved from repository, and if it failed, still have the Id. As for ViewDataExtensions, I don't like this approach much.
queen3
I was thinking of using a presentation model instead of binding directly to business objects: http://odetocode.com/Blogs/scott/archive/2009/04/05/12740.aspx, but I suppose that's a different architecture rather than a direct alternative to your idea.As for ModelStateToTempData issue, you could use the Null Object Pattern but include the requested Id as a property, instead of returning c# null values.
MVC-dot-net