views:

67

answers:

2

Consider the below:

public class DependencyA {}
public class DependencyB {}
public class DependencyC {}
public class DependencyD {}

public class Service1
{
    public Service1(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... }
}
public class Service2
{
    public Service2(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... }
}
public class Service3
{
    public Service3(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... }
}

I am finding that many of my services are dependent on multiple common components, and am thinking of implementing a catch all solution like below (all wired up through Windsor) to save repetition of code in the Service constructors.

public class DependencyContainer
{
    public DependencyA A { get; set; }
    public DependencyB B { get; set; }
    public DependencyC C { get; set; }
    public DependencyD D { get; set; }
}

public class Service1
{
    public Service1 (DependencyContainer container) { ... }
}

Alternatively I could create a ServiceBase class.

public class ServiceBase
{
    public DependancyA A { get; set; }
    public DependancyB B { get; set; }
    public DependancyC C { get; set; }
    public DependancyD D { get; set; }
}

public class Service1 : ServiceBase {}

The real question is does this highlight a wider design issue in the services?

Perhaps I am taking DI too far, but these are all genuine dependencies.

If so how do I code around this? If not is the proposed solution a valid way to achieve this goal?

+1  A: 

It's hard to talk about the issue without broader context, but you may be dealing with too fine grained dependencies. Do the four dependencies belong together? Do they make sense as one cohesive whole?

If so, your approach is very much valid.

If not, you may be hitting a wall in your architecture. You may have partitioned your domain in such a way that responsibilities that should be put in one or more (implicitly existing) entities, are attached to other entities. In this case you should look into your domain and try to identify these recurring implicit entities, make them explicit and move the behavior into them. This is however much harder issue, and very specific to your domain and application.

And it has nothing to do with IoC

Krzysztof Koźmic
+1  A: 

Having too many dependencies on your services might show that your service is doing too many things. In other words its probably violating Single Responsibility Principle.

Marek Tihkan
Your right. The very fact I raised the question it becaused something smelled. Thanks.
crowleym