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?

1
  • 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 at 16:56

1 Answer 1

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 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 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 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 at 15:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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