Repository and Services

  • Thread starter Thread starter shapper
  • Start date Start date
S

shapper

Hello,

I am following ASP.NET MVC Storefront example available in CodePlex:

http://www.codeplex.com/mvcsamples

As far as I know a Repository Interface, ICatalogRepository, defines
methods like GetProducts, GetCategories, ...

And a class inheriting that repository, for example
SQLProductRepository, defines the methods and what they return or save
in the database .. in this case using Linq.

What I am missing is: the controllers use Services (there is a
ICatalogService and CatalogService).

The problem is that it seems they do the same???

In my MVC Application I have:

1. A LinqToSql Model with two tables (classes): Article and Tag.
Each Article is related to one or many tags;
2. Two classes, MvcArticle and MvcTag that map LinqToSql classes.

MvcArticle contains the same properties as Article and an extra:
List<MvcTag>.

So when I get an Article I also need to get the tags related to it ...
and when I save an article I need to provide the tags related to it.

I need 5 methods: GetArticles, GetArticleById, CreateArticle,
DestroyArticle and UpdateArticle.

I have this methods declared in IArticleRepository and defined, using
Linq to create the funcionality, in SqlArticleRepository.

The question is: where the services should be doing and why to create
them?

Shouldn't the controller call the repository?

I am confused about this ...

Thanks,

Miguel
 
You can use a service provider pattern, or a dependency injection container
(such as unity) to obtain references to your repositories.

The reason that you obtain a reference to the repository via an interface
and a (provider mechanism of your choice) is for testing. When you write
tests you would have 1 set of tests to check the repository returns the data
it is asked to, and elsewhere you would have tests to check that your
ViewData is updated correctly from the value returned by your repository.
However, when you are testing your controller is updating your view data you
don't want to use the real repository because a failure in the repository
would make it look like there was a fault in your controller when there
wasn't

A: The database is offline
B: The data you are requesting isn't in the DB
C: The data is in the DB but the columns have different values than expected

So what you do in your controller test is to use a mocking framework like
Rhino Mocks or TypeMock, create a mock IMyRepository, register it with the
(provider mechanism of your choice). Then when your test calls the method
on your controller the controller will use the mocked repository and receive
predictable results. Predictable input = predictable test, therefore when
the controller test fails you know it is because of a fault in the
controller and not somewhere else.
 
Back
Top