Why do the clients create the repositories?

Question

Please see the code below, which I took from Jimmy Bogards Wicked domain models:

public class OfferAssignmentService
    {
        private readonly IMemberRepository _memberRepository;
        private readonly IOfferTypeRepository _offerTypeRepository;
        private readonly IOfferValueCalculator _offerValueCalculator;
        private readonly IOfferRepository _offerRepository;

        public OfferAssignmentService(
            IMemberRepository memberRepository,
            IOfferTypeRepository offerTypeRepository,
            IOfferValueCalculator offerValueCalculator,
            IOfferRepository offerRepository
            )
        {
            _memberRepository = memberRepository;
            _offerTypeRepository = offerTypeRepository;
            _offerValueCalculator = offerValueCalculator;
            _offerRepository = offerRepository;
        }

        public void AssignOffer(Guid memberId, Guid offerTypeId)
        {
            // Retreive
            var member = _memberRepository.GetById(memberId);
            var offerType = _offerTypeRepository.GetById(offerTypeId);

            // Delegate to business objects
            var offer = member.AssignOffer(offerType, _offerValueCalculator);

            // Save
            _offerRepository.Save(offer);
        }
    }

Why are the repositories injected into the service? Say I have an app, which has four clients (mobile; WPF; MVC4; Win Forms), then all these clients have to create instances of these repositories and pass them to the service. Why does the service not just create them i.e. in one place.

I am obviously missing something here.

Update

If I create the repositories in the Serivce layer then their are four dependencies i.e. one for _memberRepository; one for _offerTypeRepository; one for _offerValueCalculator and one for _offerRepository. If I create all these instances in the four clients then I am creating 16 dependencies i.e. 4*4. I realise I am missing something fundamental here.

Answer 1

Your individual clients shouldn't be responsible for knowing how to configure these dependencies in detail. If your client depends on OfferAssignmentService then it shouldn't be responsible for knowing about all of the dependencies for that class, like the repositories, and the dependencies of those repositories, etc. If that code is duplicated wherever OfferAssignmentService is used then that can be improved.

Ideally there would be a single configuration class which serves as the composition root for this service layer, and that class would be referenced and used by clients to configure the dependencies for your service. The specifics vary depending on the container you're using. For example, with Windsor I would create a class that inherits from AbstractFacility. My client would simply do this:

container.AddFacility<OfferAssignmentServiceFacility>();

That facility would handle configuring all of the dependencies with my container.

In Unity it would be a class that inherits from UnityContainerExtension, and very similar to Windsor, you would do

container.AddNewExtension<OfferAssignmentServiceExtension>();

What they have in common is that they pass the container to the configuration class, allowing that class to configure the container with the dependencies it needs.

If you don't mind your service being tightly coupled to a container framework you can put that code directly in your service library. I like to make my libraries container-agnostic (they don't need one particular brand of DI container to work.) So I'll put the facility or extension in a separate library.