Hey there. I come across a weird design pattern using the repository and service model. The application is an ASP.NET MVC, WCF and some Windows services. My repositories use LINQ DataContext. As my application evolves, I find all the links to the IWhateverService. For example, I have an IAccountService that defines methods such as ChangePlan (account, plan plan).
Now it seems that IAccountService is the best place to host this method, as we serve the accounts here. However, the ChangePlan method needs to know a few things before it can actually change the plan. He should know the user's current usage, the list of plans available, the instance for the e-commerce billing interface, etc.
I thought the ChangePlan method accepts all the necessary services in the IAccountService interface. But the requirement of these other services is an implementation issue and should not be part of the interface definition.
So now I find that I am creating a huge constructor for AccountService using an instance of IAccountRepository, IPlanService, IUsageService, IEcommerceService and IValidationDictionary. This is not entirely correct.
Now take this script. Obviously, IAccountService contains a simple method for obtaining a user account by ID: Account Get (int id). Several times when I just need to call this method. So, I'm going to create my AccountService, and it wants instances of all these other services (especially IValidationDictionary, I don't need validation for this). Again, this seems wrong. I could pass null, but this is only because I know that the implementation does not use them only for this method.
Also, to avoid instantiating the services wherever I need them, I created a static class called ServiceFactory, which has static methods, CreateAccountService, CreatePlanService, etc ... I call these methods around the application. It seems good, but I cannot shake the feeling that this is wrong.
? - ?
.