PHPackages                             grifart/nette-scoped-di - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Framework](/categories/framework)
4. /
5. grifart/nette-scoped-di

ActiveLibrary[Framework](/categories/framework)

grifart/nette-scoped-di
=======================

Multiple DI containers support for Nette DI

v0.1.0(5y ago)317.4k↓32%MITPHPPHP ~7.1 || ^8.0

Since Jan 4Pushed 2y ago2 watchersCompare

[ Source](https://github.com/grifart/nette-scoped-di)[ Packagist](https://packagist.org/packages/grifart/nette-scoped-di)[ RSS](/packages/grifart-nette-scoped-di/feed)WikiDiscussions master Synced 1mo ago

READMEChangelogDependencies (3)Versions (2)Used By (0)

Nette Scoped Depenedency Injection Container
============================================

[](#nette-scoped-depenedency-injection-container)

Split your app dependency injection container into well-defined scopes and enforce relationships between them.

On the edge between monolith and microservices
----------------------------------------------

[](#on-the-edge-between-monolith-and-microservices)

This approach stays in the middle of monolith and microservices.

From architectonical perspective it is equavalent to microservices approach. There is clear boundary and interface between *model* and *app*.

Technically you save tons of hours of maintainace cost of managing microservices. Because there is still one app, but with many independent modules. They have clear boundaries and explicitly defined dependencies. And when you break this boundary, you get an exception.

So if needed you can easily turn already defined modules into microservices later. Only part that is missing here is a serialization & networking stack. This can be easily solved by adding RPC layer between modules that are extracted into microservices.

**More resources:**

- 🎥 [Jan Kuchar: Why you need to have more then one DI](https://youtu.be/OmjQ39HWiy0?feature=shared) (english)
- 🎥 [Live stream of Jan Tvrdik's talk](https://www.facebook.com/pehapkari/videos/1604024302980707/) (Czech only)

Example
-------

[](#example)

You have *a model* where you want to expose access **only to** a few facades. So you export them from the *model* container into the *app* container, and the *app* then can **only access** those exported services. This means that *app* can no longer ignore ACL rules or directly access a database.

### Registering the model into a user DI container

[](#registering-the-model-into-a-user-di-container)

For the model container, you must create a DI extension to register all the services exported from the *model* to the user's application (UI/API/CLI/...) part of the app.

```