Give me chains, or give me death!
On my current project the component developers are moving towards constructor-based dependency injection. But here's the thing. I think that constructor-based injection looks ugly. There. I said it. I understand why it's there but it's ugly and verbose and I think that we might be using it as a workaround for more serious problems within our software architecture instead of using it for its intended purpose.
How many objects do you inject into a business object's constructor before that creates a code smell of its own? And what are the types of things that should be injected into a business object? I'm not entirely comfortable injecting business objects that our teams wrote into other business objects that our team wrote when we wrote both and we're not crossing an architectural layer. I may be wrong, but it just feels awkward.
It seems like maybe in our quest to create independent assemblies we forgot that it is possible to create logical dependency chains between assemblies and now we may be using constructor based dependency injection to work around our egregious independence.
How many objects do you inject into a business object's constructor before that creates a code smell of its own? And what are the types of things that should be injected into a business object? I'm not entirely comfortable injecting business objects that our teams wrote into other business objects that our team wrote when we wrote both and we're not crossing an architectural layer. I may be wrong, but it just feels awkward.
It seems like maybe in our quest to create independent assemblies we forgot that it is possible to create logical dependency chains between assemblies and now we may be using constructor based dependency injection to work around our egregious independence.
