# Have a class that holds all the interfaces [closed]

I seriously didn't know how to write this in Google, there must be an answer lying around. Here it goes:

I'm using Ninject (IoC) and ASP.NET MVC 5. I have a business layer with a couple of classes. Is it ok if I have one class that holds all these classes? Like this:

    public class BusinessLayer : IBusinessLayer
{
public IOrganizerLogic OrganizerLogic { get; }
public IParticipantLogic ParticipantLogic { get; }
public IPaymentLogic PaymentLogic { get; }
public ITournamentLogic TourmanetLogic { get; }

IPaymentLogic paymentLogic, ITournamentLogic tournamentLogic)
{
OrganizerLogic = organizerLogic;
ParticipantLogic = ParticipantLogic;
PaymentLogic = PaymentLogic;
TourmanetLogic = TourmanetLogic;
}

}

• You can, but it's likely just sweeping a code smell under the rug. What's your real concern? Is it the number of dependencies your classes have? This answer may be relevant if so. – RubberDuck May 13 '16 at 0:09
• This looks like a sanitized example. Could you please post your real code? – 200_success May 13 '16 at 0:14
• @200_success: That's the whole code. I'm using Ninject to inject the dependencies on each of the properties. What I'm trying to do is to create a "holder class", so I just need to reference that class. I wanted to know if it would have any severe consequences doing so in the long run. (For example, I believe this would initialize all the classes, instead of one, but the code will be much cleaner that way). – Jose A May 13 '16 at 1:01
• @RubberDuck: I'm looking for a way to instead call all those dependencies separately, have a single class that would call them... and I would just call that single class. – Jose A May 13 '16 at 1:03
• ParticipantLogic = ParticipantLogic; ? – janos May 13 '16 at 5:31

Of corse you could do that, but I think that it breaks some ideas of dependency injection:

• You can see the dependencies of a class by looking of the constrcutor (in your case, that is not possible)
• You can test classes by mock the dependencies passed to the contructor (in your case you have to mock more because the dependencies are not evident)
• You decople dependencies by passing only what you need (also not given in your case)

Instead of creating some granular dependencies of needed objects, your proposal is to create lots of dependencies from a container object that provides a set of objects. I see also the risk, that such a container object tends to grow so it makes the life easier (but conflicts with the idea behind DI).

• Brilliant! In regards of the mock, it would actually stay the same. Because I would just create a class that would auto-populate the dependencies. But heck, you're right! This would create a nightmare in case I need to do some tasks that call the same class but use different mock (In case I'm doing Behavior-Driven Unit Tests) – Jose A May 15 '16 at 0:44

This will work but is not ideal. As the number of your logic classes grow, this holder class will become unmanageable. If you absolutely need to centralise your logic classes, look into the Service Locator pattern.

A better design would be to directly inject instances of logic classes into the objects that need them instead of using this intermediary class. Thus, you have tight integration making your design more cohesive and more manageable code overall.

• Thanks a lot for the pattern. Checking Wikipedia (en.wikipedia.org/wiki/Service_locator_pattern), the disadvantages outweighs the advantages (for now). I will have it present when the application starts growing. – Jose A May 15 '16 at 0:46