First let assume that everybody agree that there is nothing wrong with injecting some value object into injectable object such as service. Indeed, a service can get another service injected, but could along the way get some configuration information as well. Configuration information that would be represented as Value object.

Now let's talk about using DI framework, on value object directly. (I intentionally do not say, let's apply dependency injection on value object, because i see the critics coming about what is a dependency and etc...)

Here is what can be red everywhere:

Using DI for Value object is wrong or useless. They are newable. They do not have real dependency.

In general i would first disagree with the idea of "newable".

I think it is a good practice to use Factories anyway. It leaves you some control over how exactly the object is created and what strategy, you may use behind and etc...

The factory itself could be configured and etc...One could even think about changing the implementation instantiated for the given interface of a value object, based on the operating system constraint or whatever condition you may think of....

Let us now assume that we all agree to use factories for value object creation. Building on that, I would like to develop the following point: Can a DI be used as a simple factory tool, when it comes to value objects?

Why I'm asking this:

Because i want to use factories as exposed above. I don't want to scattered around my value object creation. (Is that legitimate ?)

This means that i will definitely use assisted-injection all the time to create my value object (The other way would be to use static factories in my code).

In essence using a DI as factory container for you value object, means that you will be likely to pass factories as parameter of your services, to allow them to create those value objects.

Which one do you use? why ? Why would you be against one or the other ?

Do you prefer to use a static (Singleton / anti-pattern ?) in the middle of your service code, or you would rather inject your factory, weather it via a DI or a factories that non static ?

  • Eh? Services aren't the place to do injection, they're your entrypoint. That's where you setup your injection. – Telastyn Sep 25 '14 at 13:39
  • 2
    The "assisted injection" part of the title sounds like something Dr. Kevorkian did. – user22815 Sep 25 '14 at 21:04

I reject the premise of your question. Value objects, by definition, are immutable data classes that only use other value objects or primitives. I'll say that again: value objects have no dependencies, so there is no need to use an IoC-style pattern such as Abstract Factory*. A value object with dependencies is not a value object.

So, in the interest of simple design and understandable code, you should just new up your value object(s) unless you have a really compelling reason not to. Anything more complicated is overengineering.

The only use case I can think of for not using the constructor directly is if you need to choose between a number of subclasses of your value object based on some condition. (I am skeptical about how often this really happens.) In that case I would use a static factory method, not dependency injection.

* I don't think it's a good idea to use IoC for anything that is not a dependency. In particular, you should avoid using a container for classes in your domain model.

| improve this answer | |
  • Would it be a good use case for a factory method when you don't want to allow the VO to have all fields set to null (or any other invalid value)? So if all fields are passed invalid the factory returns null or null-object static instance. – Sergio Sep 29 at 21:37

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.