7

I'm new to this IoC and DI business- I feel like I get the concept if you are passing along objects that are of a global scope, but I don't get how it works when you need to pass around an object that is of a specific logical state. So, for instance, if I wanted to inject a person object into a write file command object- how would I be able to choose the correct person object dynamically? From what I have seen, I could default construct the object, but my disconnect is that you wouldn't use a default person object, it would need to be dynamic. I assume that the IoC container may just maintain the state of the object for you as it gets passed around, but then that assuems you are dealing in only one person object because there would be no thread safety, right? I know I am missing something, (maybe something like a factoryclass), but I need a little more information about how that would work.

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
mytwocents
  • 847
  • 17
  • 29

2 Answers2

7

Well, you can always inject an Abstract Factory into your consumer and use it to create the locally scoped objects.

This is sometimes necessary. See these examples:

However, in general we tend to not use DI for Entities, but mostly for Services. Instead, Entities are usually created through some sort of Repository.

Community
  • 1
  • 1
Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • So in general, Entities would not be part of the DI infrastructure at all? Am I over complicating this? – mytwocents Jan 13 '11 at 20:02
  • 2
    That's right: Entities and Value Objects tend to live separate lives. In a sense they are still somehow managed by the DI infrastructure (ideally, everything is), but in a very indirect way. They are usually read and written to permanent storage via Repositories or the like, and *those* are Services that are part of the DI infrastructure. – Mark Seemann Jan 13 '11 at 20:19
  • Ok, I thought the DI principal was saying that the person Enitity object should be made available from the IoC container (via configuration)... – mytwocents Jan 14 '11 at 14:12
  • ...and that while this is possible via a FactoryClass to create the Entity dynamically from the database (client/server architecture), it is not necessary and can be managed separately. What I am gathering is A) The person object Entity does not need to be part of the DI infrastructure/configuration only services are typically injected in this manner and B) I could add it to the DI infrastructure/Configuration if the person object itself required service objects when it is contructed, and I would use a FactoryClass to create the dynamic instance of the person Entity from the database. – mytwocents Jan 14 '11 at 14:13
  • Think of it like this: there's a known set of Services, which means that you can configure a DI Container to contain them. However, when it comes to Entities and Value Objects, there will be an unknown number of them. Thus, they are not part of the infrastructure because they are the data that you application manipulates. – Mark Seemann Jan 14 '11 at 18:32
4

When you construct an service object (e.g. WriteFileService), you inject into it things it needs internally to complete it's job. Perhaps it needs a filesystem object or something.

The Person object in your example should be passed to the service object as a parameter to a method call. e.g. writeFileService.write(person)

WW.
  • 23,793
  • 13
  • 94
  • 121
  • So you wouldn't inject the WriteFileService into the Entity person object... so in this case, I can see how the Entity may be used without the DI infrastructure. Although, the WriteFileService likely used the DI infrastructure when it was created (based on a need for an injected class that writes to a specific output e.g. WriterA - writes to database, WriterB - rights to a console etc...). – mytwocents Jan 14 '11 at 14:09