Comparing to Zenject
Zenject is awesome. However, VContainer has the following advantages:
- 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.
#
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) |