IOC issue: Too many Abstract Factories for Runtime data dependent classes

Question

I have recently started to use DI in one of my projects. For runtime dependent classes, I created corresponding Abstract factories. After following this pattern I end up having too many abstract factories, almost one for each of my class.

Is it common to end up having too many abstract factories when using IOC ?

Scenario: Suppose I get an "Entity" object from a database. There are 10 different use cases a user could perform on this entity object. For each of the usecase I have a different class to handle it. In some cases a given use case could have sub use case components which may also need the entity object. As these classes are dependent on runtime entity object, I had to create abstract factory for each one of them. Finally I wire the construction instructions in the IOC container.

Is there an alternative way of doing it. I just feel creating all these factories is waste of time, ESPECIALLY when all the sub classes are dependent on the same entity object.

I am inclined on having a single factory / builder class registered for my scenario with IOC container. This factory would create the required object graph for my scenario. I see IOC as a tool to help implement DI concept. Not using IOC container all the way may not be bad as long as I am observing DI via a custom builder / factory.

I wanted to know what do you guys think about this approach?

Answer 1

It sounds like you are suffering from an overabundance of 1:1 interfaces. When that happens it's often a sign that one should stop and think about the Reused Abstractions Principle.

Perhaps you can redesign your interfaces so that there are less factories and more commands.