[dotnet] Expand code with Interfaces and DI-configurations options

[Dragonsangel]

Code Contribution Proposal

Heya,

I have had a look at using the dotnet SDK for use in my personal and potential corporate environments.
The implementation that you so far build is elegantly simple and easy to use and I have been able to integrate my personal SM into my projects. Thanks for that.

I would like to help in expanding the implementation to support dependency injection and unit testing by creating interfaces and create service collection extensions to register and configure the BW Client at application startup, including reading settings either from the appsettings.json-Files, environment variables or a combination of them.

My idea here would be to have a IBitwardenClient-Interface that one can register at startup with a webApplicationBuild.Services.AddBitwarden(BitwardenSettings bitwardenSettings, String accessToken)-method. This method would store the accessToken in a private Property in a singleton instance of BitwardenClient.
The method BitwardenClient.AccessTokenLogin() will only be called in the moment the first request to the API is called. Alternatively, we can have a webApplication.UseBitwarden() that forces a call to AccessTokenLogin().
The implementations for ProjectsClient and SecretsClient can also be abstracted with interfaces to allow for easier unit testing of implementations.

I had a look at the roadmap and current feature requests and currently it seems there are no plans for the above mentioned.

Would this be a good change and expansion?

[justindbaur]

Hi @Dragonsangel thank you so much for your interest in our .NET SDK. We currently have a private repo with a library I helped make that integrates secrets manager secrets with IConfiguration that I think a special DI library would be a great place to land in. I think a AddBitwarden library is a really good idea. I will work on removing any secrets I may have used to test it and then make that public so we have a place to build this.

I do have concerns about adding interfaces to all the classes though, the problem is we plan on adding lots of new methods and features to those classes. It's considered a breaking change to add new methods to an interface but it's not a breaking change to add them to a class. What is a somewhat common thing to do is to make your own interface wrapping the specific feature you use and instead injecting that throughout your own application. We do on our own server repo with IStripeAdapter.

[Dragonsangel]

Thanks for the reply!
It will be great if the Repo that you have to create the NuGet Package and your current integration with the IConfiguration is made public, then we can all help with extending it with the desired functionality.
At that point I can jump in and see where I can assist.

Regarding the Interfaces vs Classes:
You make a valid point regarding adding methods to an interface being considered a breaking change.
However having to create and maintain a self created facade and interface would mean everyone that uses the package would need to implement one. Especially if they easily want to perform unit tests.
In my current implementation, I have wrapped initializing the BitwardenClient and the BitwardenClient.AccessTokenLogin() within my own class and derived interface. However I cannot create unit tests for that class unless I additionally wrap the BitwardenClient in a facade, register that with DI and use that instead of the the BitwardenClient.
I personally like having the interfaces supplied by the packages and not having to create the facades in each project that I have and having to maintain them. Currently I have 5 private projects in which I will be using the package. At my work we have a multitude of microservices that all would need this facade. There I would wrap it in an internal package, but that still needs maintenance and updates played into the microservices.

Since the package is currently still in alpha, breaking changes can occur frequently. But with the v1 release, most functionality would be implemented and methods defined. From that point onwards, new methods would probably be new functionality implemented in SM itself, which could help users of the package realize that v2 has breaking changes and is meant to be used with SM v2024.3.0 for the self-hosted versions.