Should a service be given a reference to another, or should the caller gain extra responsibility?

Question

There are two classes in my project (using ASP.NET MVC): AuthenticationService, and ProfileService. When a new user registers at my site the Authentication controller's Register action calls a Register method in IAuthenticationService, which creates an authentication record for the user according to whichever concrete authentication module the interface is referring to (injected into the controller's constructor). As part of the registration process a profile record is created for the user, which is created by calling CreateProfile(User) on the injected IProfileService.

At the moment the controller is calling both services, but I like the idea of my controller performing as little business logic as possible. I'm wondering if I have any other options besides letting the authentication service know about the profile service, which in turn would require any future implementation of IAuthenticationService to know to call CreateProfile? I can't help feel that has code smell written all over it.

Another possibility is to have a third service, {I,}RegistrationService, be responsible for the logic.

What's the recommended, or preferred way of handling this situation? Thanks

Answer 1

I like the third approach. I have a similar situation in my app where the controller needs multiple domain level services to perform a task, and the code gets a bit verbose for a controller. In particular, i have an event management system which allows for photo uploads. In addition to repositories and IAuthService, physical storage is handled by an IFileSystem (we can switch between local and S3), image manipulation by IThumbnailer, sweeping/cleanup handled by a IBackgroundTask.

What i've begun doing is create application services in addition to domain services to handle the responsibility, so that the container is now only injected primarily with app services (option 3 in your case)

Answer 2

I would go with an {I}RegistrationService which depends on the IAuthenticationService and IProfile services.

As a rule I aim to have a single Service Dependency per Controller

Answer 3

If the controller is tasked with registering users and creating profiles, whats the matter? It's OK for a controller to call multiple services. The controller serves a purpose and it doesn't have to be insanely granular.

Creating a third controller for general registration that uses an interface reference to authentication and profile would likely be the better route though. Then authentication and profiles aren't coupled.