Have Geek Brain

IOC and dynamic parameters

I have read several posts about not mixing parameters when going to constructor, but I am asking a question. I have classes and they all depend on a company parameter, all methods are company specific. I dont want to pass the company on every method call, I would like to pass that to the constructor. This complicates the classes because I have to pretty much make sure that the constructors of the concrete classes take certain parameters that I'm not a fan of (can't fit that into a contract being an interface). Recommend to just pass the company to every method call in the class ???

+1


a source to share


5 answers


If all methods require a company name, then from an OOP design point of view, it makes perfect sense to pass that company name into your class constructor. This means that your class cannot function properly without a company name, so any consumer of that class will be forced to provide the required dependency.



+4


a source


Assuming you are not working with a well-known IoC framework that already handles this for you, you can always implement this as property nesting. Not that I see a problem with this at the constructor level - you haven't really said why you feel there is a problem.



It is of course not recommended to pass it to every method (clearly redundant).

+2


a source


Yes, in the IoC world, most tools (Spring.Net, Castle Windsor, even LinFu) have methods that can take care of this for you, so you define it one in the config and each time you get a copy (from a container or whatever) something else), it is pre-configured.

You can wrap your "container" 

IWindsorContainer _ConfiguredContainer = null;

public IWindsorContainer GetContainer()
{
   if (LoggedIn == false)
      throw new InvalidOperationException("Cannot be called before a user logs in");

   if (_ConfiguredContainer == null)
   {
      _ConfiguredContainer = new WindsorContainer(new XmlInterpreter());

      // Do your 'extra' config here.
      _ConfiguredContainer.AddComponentWithProperties(/*blah blah blah*/);
   }

   return _ConfiguredContainer;
}
0


a source


If the behavior of your class depends on your company name, what is wrong passing it to the constructor? A constructor is a contract in itself - you have to create something.

0


a source


You can have ICommonSettings (almost like a global static class) that is injected into your login manager (to set the name comania) and into the object you are talking about. Then you don't need to pass it to a constructor or method.

0


a source






More articles:


All Articles