You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The entire idea of DI is to resolve all dependencies once at the app root, however current implementation of this factory extension violates that principle by resolving the object being produced by a factory and its dependencies on demand. This can lead to unexpected behavior at runtime instead of fail-fast at the startup. Such problem does not occur when you implement a factory by hand, because the compiler will do the compile-time checks.
Here is an example:
public interface IFooFactory
{
IFoo Create();
}
class Foo : IFoo
{
public Foo(IBar bar) { ... }
}
static void Main()
{
// Create bindings, but forget about IFoo and IBar
var kernel = new StandardKernel();
kernel.Bind<IFooFactory>().ToFactory();
// Resolve dependency graph at startup
var factory = kernel.Get<IFooFactory>();
// Somewhere down the stream: Oops! IFoo or one of its dependencies is not bound :(
var foo = factory.Create();
}
Those dependency checks should be done when a factory is instantiated.
The text was updated successfully, but these errors were encountered:
The entire idea of DI is to resolve all dependencies once at the app root, however current implementation of this factory extension violates that principle by resolving the object being produced by a factory and its dependencies on demand. This can lead to unexpected behavior at runtime instead of fail-fast at the startup. Such problem does not occur when you implement a factory by hand, because the compiler will do the compile-time checks.
Here is an example:
Those dependency checks should be done when a factory is instantiated.
The text was updated successfully, but these errors were encountered: