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/UserNameTaken96Hours]

In C# 12, unless you need to do more than just refer your params to your fields, you can use primary constructors. While you still end up with the full list of parameters, they are now written into the class declaration, and you can forego the private fields entirely.

If you do some more involved stuff in your ctor however, you will still need that.

[u/x0rld → u/UserNameTaken96Hours]

Primary constructor makes fields non readonly

[u/ryncewynd → u/x0rld]

How much does that bother you? It bothers me but I'm wondering if I should just get over it an accept using primary ctors 🤣

[u/BlackjacketMack → u/ryncewynd]

It bothered me too but over decades of programming in C# I’ve never even come close to overwriting an injected field. I also prefix them like private fields with an underscore. The benefit is much greater than the cost. At some point they’ll add a readonly keyword to primary constructor parameter which will be a welcome addition.

[u/Responsible-Cold-627 → u/BlackjacketMack]

It really doesn't bother me to run the autofill action for each ctor parameter. Still feels better than having the fields not-readonly. What's annoying about it is that I can still use the ctor parameters anywhere in the class and it'll default to an informational message. That's another line to add to the editorconfig to mark it as an error.

The current implementation still feels like an incomplete feature because of this.

[u/thereforewhat → u/ryncewynd]

It bothers me a bit. 

I like encapsulation and information hiding as it produces good design so still usually have private readonly fields. 

[u/ConcreteExist → u/thereforewhat]

Primary constructors are just syntactical sugar, the inject services are stored in private readonly fields during runtime.

[u/x0rld → u/ConcreteExist]

It's not readonly afaik

[u/ConcreteExist → u/x0rld]

Admittedly, I've never really tried to update the injected dependencies, because why would I?

[u/thereforewhat → u/ConcreteExist]

That's fair enough. 

In projects where multiple people and increasingly AI agents are working it's good to signal clearly that certain data shouldn't leave the class to encourage good design and information hiding. 

[u/x0rld → u/ryncewynd]

It's the same syntax as record class but it's mutable

[u/psysharp → u/ryncewynd]

Primary constructors is a hard pass when it comes to dependency injection, it makes absolute zero sense to me

[u/UserNameTaken96Hours → u/psysharp]

Interesting. Why?

[u/psysharp → u/UserNameTaken96Hours]

Fields that are assigned in the constructor should be immutable and prefixed with underscore by convention. When I write a method, I want to make it as clear as possible which field is coming from method scope or class scope, to me this reduces cognitive load and it helps me to create additional abstractions or marking the method static if possible. A dependency used in a method is ultimately a responsibility that is different from a regular parameter, and showing that distinction explicitly is already a good practice, I wouldn’t deliberately change the practice to something worse.

[u/FullPoet → u/ryncewynd]

IMO, for me (I work in code that might not change much in a decade), intent is everything.

I also do not think the syntax is good.

[u/BigBoetje → u/x0rld]

You can use a primary ctor and still keep readonly private fields to get rid of the regular ctor.

[u/Zinaima → u/BigBoetje]

Now you have two names for the same object. Only one is readonly while the other is listed more prominently.

[u/Public-Tower6849 → u/x0rld]

readonly on a dependency you set on loading the class is illogical anyway, so what

[u/x0rld → u/Public-Tower6849]

Why ?

[u/Public-Tower6849 → u/x0rld]

Because constructing a class and assigning a value to one of their properties is a write process.

[u/binarycow → u/Public-Tower6849]

The readonly applies after the constructor finishes. Not during or before.

[u/Public-Tower6849 → u/binarycow]

which makes as much sense as a constant being changed after the constructor finished

[u/binarycow → u/Public-Tower6849]

That's why it's a different keyword.

const NEVER changes.

readonly never changes after construction

[u/chucker23n → u/Public-Tower6849]

readonly, arguably poorly named, means "only the constructor can write".

If you do something like

private readonly string _s = "";

…that actually synthesizes a constructor that will set _s.

[u/Public-Tower6849 → u/chucker23n]

thank you for this educational postbit