How to use the repository pattern correctly?

Question

I am wondering how should I be grouping my repositories? Like from the examples I seen on the asp.net mvc and in my books they basically use one repository per database table. But that seems like a lot of repositories leading you to have to call up many repositories later on for mocking and stuff.

So I am guessing I should group them. However I am not sure how to group them.

Right now I made a registration Repository to handle all my registration stuff. However there are like 4 tables I need to update and before I had 3 repositories to do this.

For example one of the tables is a license table. When they register I look at their key and check it to see if exists in the database. Now what happens if I need to check this license key or something else from that table at some other spot other then registration?

One spot could be login(check if the key is not expired).

So what would I do in this situation? Rewrite the code again(break DRY)? Try to merege these 2 repositories together and hope that none of the methods are needed in some other point of time(like maybe I might have a method that checks if userName is used - maybe I will need that somewhere else).

Also if I merge them together I would either need 2 service layers going to the same repository since I think having all the logic for 2 different parts of a site would be long and I would have to have names like ValidateLogin(), ValdiateRegistrationForm(),ValdiateLoginRetrievePassword() and etc.

Or call the Repository anyways and just have a weird sounding name around?

It just seems hard to make a repository that has a general enough name so you can use it for many spots of your application and still make sense and I don't think calling another repository in a repository would be a good practice?

Answer 1

One thing that i did wrong when played around with repository pattern - just like you, i thought that table relates to repository 1:1. When we apply some rules from Domain Driven Design - grouping repositories problem often disappears.

Repository should be per Aggregate root and not table. It means - if entity shouldn't live alone (i.e. - if you have a Registrant that participates in particular Registration) - it's just an entity, it doesn't need a repository, it should be updated/created/retrieved through repository of aggregate root it belongs.

Of course - in many cases, this technique of reducing count of repositories (actually - it's more a technique to structure your domain model) can't be applied because every entity is supposed to be an aggregate root (that highly depends on your domain, I can provide blind guesses only). In your example - License seems to be an aggregate root because you need to be able to check them with no context of Registration entity.

But that does not restrict us to cascade repositories (Registration repository is allowed to reference License repository if needed). That does not restrict us to reference License repository (preferable - through IoC) directly from Registration object.

Just try not to drive your design through complications provided by technologies or misunderstanding something. Grouping repositories in ServiceX just because you don't want to construct 2 repositories ain't good idea.

Much better would be to give it a proper name - RegistrationService i.e.

But services should be avoided in general - they often are cause that leads to anemic domain model.

EDIT:
Do start to use IoC. It truly eases the pain of injecting dependencies.
Instead of writing:

var registrationService = new RegistrationService(new RegistrationRepository(),         new LicenseRepository(), new GodOnlyKnowsWhatElseThatServiceNeeds()); 

you will be able to write:

var registrationService = IoC.Resolve<IRegistrationService>(); 

P.s. Would be better to use so called common service locator but that's just an example.