Welcome to Pure.DI Discussions!

[NikolayPianikov]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[jeffward01]

Very cool library and excellent documentation!!

Sorry for the stupid question, but to me it seems that it requires roughly the same amount of code as classic Microsoft.Extensions.DependencyInjection, in addition to the expected learning curve to using your library.

I have a few quick questions on understanding the advatages your library offers over Microsoft.Extensions.DependencyInjection.

Question 1
Can you explain why a developer (such as myself) would want to use your library to create a nuget application or basic CRUD application?

Question 2
What advantages does your library offer which 'solves' painpoints in classic Microsoft.Extensions.DependencyInjection, and what are those pain points?

---

Thanks so much for the excellent documentation! I know once I have a small chat with you or other developers I will have that 'Ah ha!' moment and better understand the advantages and use-cases where one would want to use your very cool library.

Thanks!

[NikolayPianikov]

@jeffward01 thank you for your feedback.

First of all, the main difference is you could consider Pure.DI is not as some framework or a library but as a tool. Briefly, this tool builds a static method to create a composition of objects in the DI paradigm by a set of hints. This difference brings several significant benefits:

• All logic for analyzing the graph of objects, constructors, methods takes place at compile-time. Thus the tool notifies a developer about missing some dependencies, cyclic dependencies, when some dependency is not suitable for injection, etc., at the compile-time. Developers have no chance to get a program that will crash at runtime due to these errors.

• Actually Pure.DI is a .NET code generator. It generates a simple code this way as you would do if you did it by yourself: de facto just a set of nested constructors. And you can see this code anytime. The logic of ordinary libraries can be very complex and can be changed at runtime, for instance, when you make some calls to the DI/IoC library API.

• All this magic is happening at the same time while you are writing your code. So you have instantaneous feedback between you have done some changes in your code, and you will have a fully verified code for creating an objects graph. Otherwise, the tool notifies you about errors if something goes wrong.

• All generating code works as fast as your own in Pure DI style, including compile-time and runtime optimizations. As I wrote above, the graph analysis is executed at the compilation stage. At the runtime, there is simply a set of nested constructors, and that's it.

• Using Pure.DI, you do not add any runtime dependencies to your assemblies. So there are no references to other assemblies at all.

but to me it seems that it requires roughly the same amount of code as classic Microsoft.Extensions.DependencyInjection

Yes, it was a deliberate decision. The main reason is that programmers do not have to learn a new API since the proposed API is very similar to other DI/IoC libraries.

Resuming, I would like the C# language to better support programmers in following SOLID principles. Still, we have what we have so far, and I hope this tool would help do this with minimal impact on complexity, performance, code size, number of dependencies, etc.

And thank you for your feedback again :)