views:

61

answers:

1

Hey guys, It's 5 am here, I was doing some code... when this came out:

public interface IViewModel { }

public interface IToViewModel<T> where T : IViewModel { }

public static class MvcExtensions
{
    public static T ToViewModel<T>(this IToViewModel<T> self)
        where T : IViewModel
    {
        var instance = Activator.CreateInstance<T>();

        //this line just copys the properties with the same name from one object to another
        self.Reflected().CopyMatchingPropertiesTo(instance /*destiny*/);

        return instance;
    }

}

My point with this code is do stuff like that:

public partial class UserInfo : IToViewModel<UserInfoViewModel> { }

public class UserInfoViewModel : IViewModel
{
    [DisplayName("UserId")]
    public Guid UserId { get; set; }

    [DisplayName("User name")]
    public string Username { get; set; }

    [DisplayName("Email address")]
    public string Email { get; set; }
}

public ActionResult Index(string username)
{
    UserInfo userInfo = UserInfoHelper.Load(username);

    UserInfoViewModel userInfoViewModel = userInfo.ToViewModel();            

    return View(userInfoViewModel);
}

Oks, this code runs ok, np.

But my question is about the uses of the interfaces...

My goal is convert a EntityFramework object into a ViewModel to use with ASP MVC views without doing to much parameters passing, i found in the interfaces a way to say what is each of the objects are, what they perform.

What looks weird to me is these interfaces with no method inside.

So what you guys think about it? Is there somewhere some cool blogpost/doc/etc about it? Do u have any idea how do it better? Should I go bed right now?

Other thing, .Net is bringing a lot of new ways of doing things... like linq, lambda, extension methods, expression trees... is there any study about "good practices" with these things?

I think that is huge, and makes your brain think different in the time that you are solving the problem... I would like to see what people are thinking/doing with that.

Thanks in advance

+2  A: 

I guess it could be a question of marker interfaces vs. functional interfaces. I'm not usually a fan of marker interfaces, but I can see why you would want to use it this way.

Personally, I think you should have an overloaded constructor:

public class UserViewModel
{
  // Constructor used in model binding.
  public UserViewModel() { }

  // Constructor used for mapping.
  public UserViewModel(UserEntity entity)
  {

  }
}

I have this preference because it cleanly defines a dependancy I need. I know you lose some of the fidelity of applying it to any types, but I think its cleaner.

The other alternative is to go the AutoMapper route. With AutoMapper you can easily map between one type and another...e.g.

Mapper.CreateMap<UserEntity, UserViewModel>();

public static TTarget Map<TSource, TTarget>(this TSource instance)
{
  return Mapper.Map<TSource, TTarget>(instance);
}

var user = DataContext.Users.Where(u => u.Username == "Matt").Single();
return user.Map<UserViewModel>();

Now, you have to create a specific mapping ahead of time, but then your extension method can be used on any types that you have created a mapping for. The default behaviour of AutoMapper is to map between properties that match, but you can get specific and map properties specific ways as well.

Matthew Abbott
thanks Mathew, nice POVs.. I liked better the AutoMapper suggestion, but I will play more w/ that before use it.. but I agree the overload, seems more clear, especially for other peoples looks...
Leo Nowaczyk