Reputation: 9167
I'm after a bit of advice here, so I go in the right direction.
I had one service, which did all my business functions in one service, such as:
TestingService
GetProducts()
GetPeople()
Now, I feel, as my system is growing, I want to split these out, so:
ProductService
GetProducts()
PeopleService
GetPeople()
Is the best approach for this to have two .svc files in the same project and call them each individually? I've implemented a repository pattern which is working nicely, and now have IProductService and IPeopleService. If I was to do this, and I used both constructors in my Controller - I'd get something like this:
public TestController(IProductService productService, IPeopleService service)
rather than
public TestController(ITestService service)
which I had originally.
Which could become unwieldy if I'm using 5 services in a single Controller? Is this what Factory classes are used for, as a Service-level wrapper?
Upvotes: 2
Views: 161
Reputation: 5224
I think you'll want to have your services in repository classes not the controllers. Something like this:
public TestRepository(IProductService productService) {}
If you opt for the more granular approach that you mention, you'll have many services instead of one large one - good idea. Also, if you have a 1 to 1 to 1 relationship among your controller/repository/service, then you'll have nice and maintainable structure.
However, if your relationship is 1 to many, then a factory approach is certainly an option. Maybe something along these lines:
// Factory
public class ServiceFactory : IServiceFactory
{
public IProductService GetProductService()
{
return new ProductService();
}
public IPeopleService GetPeopleService ()
{
return new PeopleService ();
}
}
// Repository
public class ProductRepository
{
public void DoSomething()
{
// use dependecy injection to avoid this tight coupling
var factory = new ServiceFactory();
var service = factory.GetProductService();
service.DoMyStuff();
}
}
Upvotes: 3