# My thoughts about DI, dry-container, dry-auto\_inject, dry-system

**URL:** <https://discourse.dry-rb.org/t/my-thoughts-about-di-dry-container-dry-auto-inject-dry-system/647>\
**Category:** Uncategorized\
**Created:** [November 7, 2018, 10:46am UTC](https://discourse.dry-rb.org/t/my-thoughts-about-di-dry-container-dry-auto-inject-dry-system/647 "2018-11-07T10:46:39Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![bsielski](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.dry-rb.org/bsielski/32/359_2.png) [@bsielski](https://discourse.dry-rb.org/u/bsielski)\
**Post date:** [November 7, 2018, 10:46am UTC](https://discourse.dry-rb.org/t/my-thoughts-about-di-dry-container-dry-auto-inject-dry-system/647/1 "2018-11-07T10:46:39Z")

</div>

I don’t have any commercial experience and I have made only simple apps as my hobby and education, and I have just write one very simple application using dry gems, so I am not sure my thoughts make any sense, but I want to share them.

I like the idea of small function-like objects because I don’t know how to create and organize bigger objects. With small objects I don’t have to think how to design them, because if they do just one thing, then it is just a one way to design them. I have noticed that with this approach I have to use many objects (like 40 for a simple console calculator), but most of them are reusable control flow objects and only about 20% of them are objects that I must create from scratch (and they are very simple).

This small objects are connected in a dependency tree graph and it is not possible to track this tree (it is growing and changing) without having a graphical image of it. I use a mind map tool for this.

dry-container is very helpful especially because it can stub objects during integration tests.

dry-system is good because it automatically registers objects. But this alone is not very helpful. The best thing is auto-registering plus auto-injecting. Because those things together allow to create objects that are close to root of the dependency tree automatically.  
And I don’t know yet if it can automatically register for example a Hash or Array or it must be always a custom class defined in a file with a proper name.

dry-auto\_inject is IMO the less helpful. I think I can do the same thing with just writing regular initialize methods with default arguments (taken from a container). dry-auto\_inject has only two strategies of passing arguments and it forced me to rewrite a class because my class was expected arrays of objects (they were registered by the container) or regular args mixed with keyword args and I think dry-auto\_inject could not handle those things.