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
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)