docs: Improved DI documentation (#2407)

docs/guides/dependency_injection/services.md

@@ -0,0 +1,48 @@
+---
+uid: Guides.DI.Services
+title: Using DI in Interaction & Command Frameworks
+---
+
+# DI in the Interaction- & Command Service
+
+For both the Interaction- and Command Service modules, DI is quite straight-forward to use.
+
+You can inject any service into modules without the modules having to be registered to the provider.
+Discord.Net resolves your dependencies internally.
+
+> [!WARNING]
+> The way DI is used in the Interaction- & Command Service are nearly identical, except for one detail:
+> [Resolving Module Dependencies](xref:Guides.IntFw.Intro#resolving-module-dependencies)
+
+## Registering the Service
+
+Thanks to earlier described behavior of allowing already registered members as parameters of the available ctors,
+The socket client & configuration will automatically be acknowledged and the XService(client, config) overload will be used.
+
+[!code-csharp[Service Registration](samples/service-registration.cs)]
+
+## Usage in modules
+
+In the constructor of your module, any parameters will be filled in by
+the @System.IServiceProvider that you've passed.
+
+Any publicly settable properties will also be filled in the same
+manner.
+
+[!code-csharp[Module Injection](samples/modules.cs)]
+
+If you accept `Command/InteractionService` or `IServiceProvider` as a parameter in your constructor or as an injectable property,
+these entries will be filled by the `Command/InteractionService` that the module is loaded from and the `IServiceProvider` that is passed into it respectively.
+
+> [!NOTE]
+> Annotating a property with a [DontInjectAttribute] attribute will
+> prevent the property from being injected.
+
+## Services
+
+Because modules are transient of nature and will reinstantiate on every request,
+it is suggested to create a singleton service behind it to hold values across multiple command executions.
+
+[!code-csharp[Services](samples/services.cs)]
+
+