Question

Or I don’t understand this at all.

I have started my ASP.NET MVC application using the Controller –> ViewModel –> Service –> Repository pattern.

Does every type of object (Customer, Product, Category, Invoice, etc..) need to have it’s own repository and service? If so, how do you bring common items together?

I mean there are a lot of the times when a few of these things will be displayed on the same page. So I am not getting this I don’t think.

So I was thinking I need a ShopController, which has a ShopViewModel, which could have categories, sub categoires, products, etc. But the problem, for me, is that it just does not seem to mesh well.

Maybe ASP.NET WebForms were for people like me 🙂

Edit

So would an aggregate consist of say:

Category, SubCategory, Product, ChildProduct, ProductReview with the Product being the aggregate root?

Then in the ViewModels, you would access the Product to get at it’s child products, reviews, etc.

I am using entity framework 4, so how would you implement lazy loading using the repository/service pattern?

Answer 1

Does every type of object (Customer,
Product, Category, Invoice, etc..)
need to have it’s own repository

You should have a repository per aggregate root in your domain. See this question for more information on what is an aggregate root.

In the example you give I could see a CustomerReposiotry which would handle retrieve all pertinent customer data(Customer has orders a order has a customer). A ProductRepository that handles retrieving product information.

and service? If so, how do you bring
common items together?

A service layer is nice but only if there is added value in adding this layer. If your service simply passes straight into the repository it might not be needed. However if you need to perform certain business logic on a Product a ProductService might make sense.

This might not make sense

public void UpdateProduct(Product product)
{
  _repo.Update(product);
}

But if you have logic this layer makes sense to encapsulate your business rules for products.

public void UpdateProduct(Product productToUpdate)
{
  //Perform some sort of business on the productToUpdate, raise domain events, ....
  _repo.Update(productToUpdate);
}

So I was thinking I need a
ShopController, which has a
ShopViewModel, which could have
categories, sub categoires, products,
etc. But the problem, for me, is that
it just does not seem to mesh well.

If the domain is flushed out the view model ends up making sense

public ActionResult Index()
{
  ShopViewModel shopViewModel = new ShopViewModel();
  shopViewModel.Products = _productRepo.GetAll();
  //other stuff on the view model.
  return(shopViewModel);
}

Update

What happens when you also need to
provide data unobtainable from an
aggregate root? For example, say I
have a create Customer view and in
that view, I also need to provide the
user with a collection of Companies to
choose from to associate a new
customer with. Does the collection of
Companies come from CustomerRepository
or would you also need a
CompanyRepository?

If a Company can live by itself (e.g. you edit, update, delete a company) I would suggest a Company is also an aggregate root for your domain (A Customer has a company and a company has a list of Customers). However if a Company is only obtainable via a Customer, I would treat a company as a ValueType/Value Object. If that is the case I would create a method on the customer repository to retrive all CompanyNames.

_repo.GetAllCompanyNames();