0

I have app which uses IOC container. I have services registered in container, and I can consume either data factory, or particular data object. Which approach is preffereable?

Consuming factory object:

DiContainer.Register(ConfigurationFactory);

class Service
{
    Configuration _configuration;

    Service(OperationContext context, ConfigurationReader configReader)
    {
        _configuration = configReader.Get(context);
    }
}

I can also register my classes:

class ConfigFactory
{
    ConfigFactory(OperationContext context, ConfigurationReader configReader)
    {
         _context = context; _configReader = configReader;
    }

    Configuration Get()
    {
         return _configReader.Get(_context);
    }
}

DiContainer.Register(ConfigurationFactory);
DiContainer.RegisterFactory(ConfigurationFactory, ConfigurationFactory.Get).As(Configuration).InstancePerRequest();

class Service
{
    Configuration _configuration;

    Service(Configuration configuration)
    {
        _configuration = configuration;
    }
}

Which approach is preferable?

The factory allows customers to depend only on what they really need, and better express the intent - but does it, or is it just unnecessary noise in code?

2
  • Can you clarify a couple of points? (1) Based on InstancePerRequest, this seems like a web app; when you say "service", do you mean a thing used by other code in your own project (client code)? With that client code implementing your business logic? Or is your service something that handles web requests (basically) directly? (2) Is configReader.Get simply manipulating some in-memory object (a quick operation returning a result), or is it doing something heavier (like reading a config file or reaching out to a config table in a database)? Feb 22, 2022 at 16:56
  • 1
    I don't understand the question. Are you not just asking "should I create an additional factory or not?". If that is the case, the first and foremost question is why you need this additional step - what does it do for you that the simpler approach doesn't?
    – Flater
    Aug 16, 2023 at 23:51

2 Answers 2

2

DI containers are a kind of really smart factory, one that can be configured at runtime instead of hardcoded, and can serve up pretty much any type and any of its dependencies (provided they have been registered).

The question is why you feel you need a factory on top of that. You seem to imply that is it relevant in every scenario, I argue that it mostly isn't.

However, there are cases such as:

  • When the dependency can only be constructed when the service is already in flight (e.g. depending on method parameters)
  • When the dependency needs to be created "now" even if the service was created in "the past" (e.g. because the data store might have changed, or it's a different time of day, or...)
  • When the service needs to be able to generate an arbitrary amount of dependencies, not just the one.

Essentially, when the lifecycle of the service and the dependency are notably different, factories can become the proxy dependency that can be injected (thus matching the service's lifecycle) and which helps define the different dependency lifecycle (calling the factory's method when appropriate).

You don't need that by default, but I cannot judge your particular scenario.

0

Asking "which is preferable" is almost never a good question in software development, because the answer depends on your requirements.

In this case:

  • If different Service objects need different Configuration objects then you need the factory because you can't meet your requirements by injecting the configuration object.
  • If they don't, Keep It Simple, <term of your choice beginning with S>. There is no need to create a factory for the configuration object, so don't.

More generally, I would suggest stepping back and thinking about why you might want a factory in certain cases; "Because it's a design pattern" is not a good answer.

4
  • If you want, you can have different context for factory (OperationContext in the example) in different lifetime scopes, so it would not be a blocker.
    – Shadow
    Feb 22, 2022 at 14:59
  • Why I'd need factory - I think it simplifies clients, because they do not really need factory - they won't make different configurations in different contexts etc. So depending just on actual Configuration makes customers more clear. Also usually you have many clients for that configuration, so it may be valuable to do it.
    – Shadow
    Feb 22, 2022 at 15:01
  • I don't have any clients for your configuration at all. You might do but you are in fact just reinforcing the general point - it depends on your requirements. Feb 22, 2022 at 15:05
  • It's demonstrated in question - Service. You may have more similar classes, Service1, Service2, ..., ServiceN. General principle is the same.
    – Shadow
    Feb 22, 2022 at 15:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.