There is something like this, I will describe in a very schematic way:

Bind<IUnitOfWork>().To<UnitOfWork>(); Bind<ISomeService>().To<SomeService>(); class UnitOfWork : IUnitOfWork, IDisposable { public Dispose(){} } // Это что то вроде GodObject (прим. фасад, методы которого, дергают кнопочки из WinForms, существует пока существует форма, ) // IDisposable не реализует class SomeService : ISomeService { IUnitOfWork readonly _uow; public SomeService(IUnitOfWork uow) { this._uow = uow; } public void Method1() { this._uow.SomeAction1(); } public void Method2() { this._uow.SomeAction2(); } }

The question is: how much reasonable is the decision to slap the solid IUnitOfWorkFactory (Ninject.Extensions.Factory) and implement the dependency instead of the constructor argument, with a factory, something like the following code:

 Bind<IUnitOfWork>().To<UnitOfWork>(); // Здесь можно обозначить Scope, если реализации репозиториев зависят // от DbContext, и нужно сохранять один экземпляр на весь UnitOfWork // прим: Bind<IUnitOfWork>().To<UnitOfWork>().DefinesNamedScope("SingleDbContextScope"); // а DbContext биндить так: Bind<SomeDbContext>().ToSelf().InNamedScope("SingleDbContextScope"); Bind<IUnitOfWorkFactory>().ToFactory(); Bind<ISomeService>().To<SomeService>(); // Это что то вроде GodObject (прим. фасад, методы которого, дергают кнопочки из WinForms, существует пока существует форма, ) class SomeService : ISomeService { readonly IUnitOfWorkFactory _uowFuctory; public SomeService(IUnitOfWorkFactory uowFuctory) { this._uowFuctory = uowFuctory; } public void Method1() { using(var uow = _uowFuctory.Create()) { this.uow.SomeAction1(); } } public void Method2() { using(var uow = _uowFuctory.Create()) { this.uow.SomeAction2(); } } }

Or there are some other solutions to this problem, and it looks like an injection through a factory, even if it is not solid, it is not a ctor injection at all

    1 answer 1

    There is such a rule / recommendation: the resource must release the one who creates it.

    If you stick to it, then two options:

    • the object is created by the container, which means you need to use scopes
    • the object is created in the facade, which means you need to use the factory and using

    If for some reason you don’t fit your scopes (and you can’t screw them in any place beautifully), then a factory is quite a good option. The fact that you are introducing a factory, and not the object itself, should not confuse you.

    You can also consider a mixed solution: the object is created by the container, but is released in the facade. But this requires the implementation of IDisposable façade, which can pull new issues with it, plus there is a jumble of styles in the release of resources. But sometimes this option can be the cheapest.

    • With areas of visibility and ctor injection is understandable, but what if TTL at SomeService is big enough, as a result, UoW local cache will become more "littered" and in fact is MemLeak, which is not good at all ... Solution with factory and ContextPreservation the most obvious, I just wanted to know if there is an alternative to the factory in the case of a long lifetime of a dependent object ... - kimaman2
    • @ kimaman2 if so, then all the more you follow the right path. I do not think of another option. - andreycha
    • Similarly, nothing comes to the head except for the factory and using ... - kimaman2