Comparing to Zenject
Zenject is awesome. However, VContainer has the following advantages:
- Good performance.
- Most parts of reflections and assertions are isolated to the Container's build stage.
- Easy to read implementation.
- VContainer has carefully selected features and does not register data-oriented objects in the container or actively inject the View component. This prevents the DI declaration from becoming overly complex.
- Zenject is often used to inject into dynamic or datacentric objects, but this is complicated
- In VContainer, injection of MonoBehaviour is recommended over injection into MonoBehaviour.
- Zenject looks up all GameObjects in reflection when the scene starts, but this operation is expensive; VContainer does not do this.
#
Code size (v1.3.0)#
API difference#
BasicZenject | VContainer |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#
ComponentZenject | VContainer |
---|---|
|
|
|
|
|
|
|
|
|
|
#
Factory#
Factory with parameterZenject
VContainer
#
Factory with parameter & resolve dependency at runtimeZenject
VContainer
#
Factory with prefabZenject
VContainer
#
MiscZenject | VContainer |
---|---|
Signal | Not supported The central messaging pattern is useful, but depends largely on the style of the project, and the preferred implementation will vary. You can choose any implementation of UniRx.MessageBroker, UniTaskPubsub or etc. |
Memory Pool | Not supported Currently, any Memory pool implementation is not embed. Please inject the implementation according to the purpose of the project into Factory etc. |
| Not Supported We should load Resources using LoadAsync family. You can use RegisterInstance() etc after loading the Resource. |
| Not supported Duplicate type Resolve is not recommended. You can instead use type-specific Register builder.Register(Lifetime.Scoped).WithParameter("foo", foo) |