Currently, the IoC mechanism (Guice) is under-utilised. Improving the use of IoC will help improve the consistency of the platform code, ultimately making it easier to understand how various subsystems interact and relate to each other.
There are several places where IoC can be improved:
Stores injected dependencies in fields and provides accessors for them, effectively under utilising
the functionality of IoC. This should be avoided as this approach is contagious and has,
in fact, spread to some other classes.
Instead, dependencies should be obtained in the usual way, through the injector. In places where a
dependency is required during the configuration of a module, Provider should be used as a
lazy-loading mechanism.
Performs heavy lifting in the constructor through HibernateConfigurationFactory, inheriting
all penalties of the imperative style. This is mainly because those dependencies are required by
the SessionInterceptor. Again, Provider to the rescue.
The only variable and non-injectable part of this class is session, all other parts are injectable.
Therefore, there is no need to accumulate the constant injectable components in
CommonEntityDao, which makes the class heavier and hinders evolvability.
An alternative approach is to split QueryExecutionContext into variable and non-variable
injectable parts.
[x] 3. Structure of Guice modules.
Currently Guice modules form a type hierarchy. This has the advantage of guaranteeing that
dependent modules are always used together, preventing Injector configuration mistakes.
On the other hand, there are also drawbacks to this approach:
~~Customisation of a module (e.g., specifying a different binding) can only be achieved through
the module's constructor arguments. Since modules form a hierarchy, those arguments will have to
be passed through all subtypes of the module.~~
Modules.override can be used on the most specific module to override bindings anywhere in the
module hierarchy.
An alternative approach is to have a flat hierarchy. In its simplest form it lacks the dependency guarantee,
but is more modular, easier to understand and lends itself better to customisation (either through Guice
Modules.override or simply by using a different module).
[x] 4. Guice guidelines
This issue is a good opportunity to populate TG Wiki with guidelines for using Guice.
Expected outcome
Use of dependency injection is made more consistent. Guidelines for effective application of Guice are established.
Description
Currently, the IoC mechanism (Guice) is under-utilised. Improving the use of IoC will help improve the consistency of the platform code, ultimately making it easier to understand how various subsystems interact and relate to each other.
There are several places where IoC can be improved:
[x] 1.
ua.com.fielden.platform.ioc.TransactionalModuleinjector. In places where a dependency is required during the configuration of a module,Providershould be used as a lazy-loading mechanism.HibernateConfigurationFactory, inheriting all penalties of the imperative style. This is mainly because those dependencies are required by theSessionInterceptor. Again,Providerto the rescue.[x] 2.
ua.com.fielden.platform.entity.query.QueryExecutionContextThe only variable and non-injectable part of this class is
session, all other parts are injectable. Therefore, there is no need to accumulate the constant injectable components inCommonEntityDao, which makes the class heavier and hinders evolvability.An alternative approach is to split
QueryExecutionContextinto variable and non-variable injectable parts.[x] 3. Structure of Guice modules.
Currently Guice modules form a type hierarchy. This has the advantage of guaranteeing that dependent modules are always used together, preventing Injector configuration mistakes. On the other hand, there are also drawbacks to this approach:
Modules.overridecan be used on the most specific module to override bindings anywhere in the module hierarchy.An alternative approach is to have a flat hierarchy. In its simplest form it lacks the dependency guarantee, but is more modular, easier to understand and lends itself better to customisation (either through Guice
Modules.overrideor simply by using a different module).[x] 4. Guice guidelines
This issue is a good opportunity to populate TG Wiki with guidelines for using Guice.
Expected outcome
Use of dependency injection is made more consistent. Guidelines for effective application of Guice are established.