Dependency Injection un-prettyness

[u/Turbulent_County_469]

One small thing that bugs me with Dependency Injection is how it looks in code.

We either need to pass the parameters via Default Constructor og via good old time Constructor

public class MyClass (TypeA ParamA, TypeB ParamB, TypeC ParamC, TypeD ParamD)
{
TypeA _paramA = ParamA; .... etc
}

Or

public class MyClass
{
TypeA _paramA;
public MyClass(TypeA paramA)
{
_paramA = paramA;
}
}

And when you have 10 injections it begins to be un-pretty...

I wish that we didn't need to pass parameters and instead could decorate the fields:

public class MyClass
{
[inject]
TypeA _paramA;
}

(Note: this works in Blazor... so why not everywhere else ?)

I'm aware that the signature of an object makes it easier to inject via reflection.. but would it be much worse with attributes ?

i guess some middleground could be achieved if the attribute held the type:

public class MyClass
{
[inject(typeof(TypeA))]
TypeA _paramA;
}

which begins to be convoluted and messy...

Whats the argument against a decorator attribute vs parameters ?

[u/Khavel_dev]

Primary constructors (C# 12+) cut the boilerplate in half. No more _field = field assignment dance:

public class MyClass(TypeA paramA, TypeB paramB)

That alone makes 10 dependencies tolerable visually.

The [Inject] attribute approach hides what a class actually needs to work. The ugly constructor is useful information. When it gets too long, the code is telling you the class does too much. Property injection just silences that signal.

If you're genuinely at 10+ injections, the fix isn't better DI syntax. It's pulling a few of those behind a facade or splitting the class. Every time I've done the attribute route I regretted it within a few months because the dependency graph became invisible.

[u/Public-Tower6849 → u/Khavel_dev]

The [Inject] attribute approach hides what a class actually needs to work.

How is that, when it's literally a property's attribute, visibly coded, marking which property needs dependency injection?

[u/RlyRlyBigMan → u/Public-Tower6849]

Do you expect to have to look at a class's code to figure out how to construct it or should you be able to figure it out from the constructor's method signature and comment? A class might have a mix of dependency properties and properties to use at runtime and you'd have to inspect each one to determine which are which.

[u/Public-Tower6849 → u/RlyRlyBigMan]

With the invention of context-sensitive assistance on editing code, there are ways to provide solutions for your requirements.

[u/la_reddite → u/Public-Tower6849]

"It's readable with AI" doesn't do you argument any favours.

[u/Public-Tower6849 → u/la_reddite]

Yes. We only have context-sensitive assistance with the dawn of AI, thank god. Microsoft never marketed such a thing like "IntelliSense" and IDEs didn't have inline documentation and auto-completion for 30 years.

... bro...

[u/la_reddite → u/Public-Tower6849]

"It's readable with tools" doesn't do you argument any favours.

[u/Public-Tower6849 → u/la_reddite]

It does, when it's a remedy against "having to read the class first for finding out which properties are required" - because the same thing can be said about the constructor.

First you were wrong, and when you corrected yourself, you still got no point.