CODEWITHSUNDEEP
asp.net-mvcviewmodelrepository-pattern
sarsnake
sarsnake

Reputation: 27703

Repository and ViewModel in asp.net mvc 3

Here is the situation I am struggling with. I have an Object Model:

public class MyModel 
{
  public string Prop1 {get; set;}
  public string Prop2 {get; set;}
//etc
  
}

Then I have Object ModelView

public class MyModelView
{
  public MyModel MyModelObject;

  public SelectList PropToBeSelected1 {get; set;}
  public SelectList PropTobeSelected2 {get; set;}
 //etc
  
}

I have the MyModelRepository class as well that does the delete, update operations for MyModel.

All good and clear so far.

Question: PropToBeSelected1 and PropTobeSelected2 are drop down lists whose contents come from the database. Should the methods retrieving these contents be put in my MyModelRepository? Or should I create another repository for ViewModel?

Upvotes: 3

Views: 2731

Answers (2)

jasonhooten
jasonhooten

Reputation: 46

First you really don't want domian-ish objects in your viewModel. Your viewModel should be clean with only primitives (like strings, ints... etc). So I'd suggest using a AutoMapper to map your two string props to your viewModel.

With the select list, there are many ways to go about this but I can imagine if they are lists of properties then they are not actual entities, but value objects instead. In this case creating a repository for them is over kill and boarders bad design.

I'd put the 'get' of the property lists in your MyModelRepository. Something like

_myModelRepository.getProperties1For(myModel);

Then AutoMap again on to get your select list.

Edit: Like @M.Radwan pointed out for complex domain models I'll make viewModels insdie viewModels for easy of mapping.

Domain Model--

public class User : Entity
{
   public Address Address { get; set; }
}
public class Address
{
   public string Street {  get; set; }
   public string Zip { get; set; }
}

would map to

public class DetailsViewModel
{
  public int Id { get; set; }
  public string Name { get; set; }
  public AddressViewModel Address { get; set; }
  
  public class AddressViewModel
  {
    public string Street { get; set; }
    public string Zip { get; set; } 
  }
}

which in our experience has been the only reason to add any complexity to your viewModel. We will put SelectLists in our viewModel though but lately we've been using IEnumerables of inner viewModels and calling custom EditorFor or DisplayFor to turn them into a dropdown / list of checkboxes / radio buttons.

Upvotes: 1

Mohamed.Radwan -MVP
Mohamed.Radwan -MVP

Reputation: 2744

The answer is NO, you should not make any repository for them if you really need them with this view. so they probably are value objects as @jasonhooten said and they should connected to the main aggregate object that used by the repository

Finally I don't decide the ViewModel structure until I finish the view and make it working first and this why I founder and create DevMagicFake, by using DevMagicFake you will delay all decisions of the design regarding the structure of the ViewModel or the repository or how you will use service layer, all this will be delayed after full complete your view and make it working first as BDD (Behavior Driven Development) and TDD (Test Driven Development) so you can take the right decisions of the design and the object model itself

So I just create the action method as the following

        public ActionResult List(MyModelView myModelView)
    {
        FakeRepository<MyModelView> repository = new FakeRepository<MyModelView>();
        repository.Add(myModelView);
    }

This fake repository will enable me to save and retrieve my whole model even it's a complex model until I finish and complete the whole view and make it working first, and then I start thanking on how the real design and the real repository should looks like, and do on

For more information about DevMagicFake and this approach see this link

DevMagicFake on CodePlex

Upvotes: 1

Related Questions