Jak pogodzić IDisposable i MKOl?

Zdecydowanie nie chcesz wywoływać Dispose () na obiekcie, który został wstrzyknięty do twojej klasy. Nie możesz zakładać, że jesteś jedynym konsumentem. Najlepszym rozwiązaniem jest zawinięcie niezarządzanego obiektu w jakiś zarządzany interfejs:

public class ManagedFileReader : IManagedFileReader
{
    public string Read(string path)
    {
        using (StreamReader reader = File.OpenRead(path))
        {
            return reader.ReadToEnd();
        }
    }
}

To tylko przykład, użyłbym File.ReadAllText (path) jeśli próbowałem odczytać plik tekstowy na ciąg znaków.

Innym podejściem jest wstrzyknięcie fabryki i samodzielne zarządzanie obiektem:

public void DoSomething()
{
    using (var resourceThatShouldBeDisposed = injectedFactory.CreateResource())
    {
        // do something
    }
}

To też często mnie zastanawiało. Choć nie jestem z tego zadowolony, zawsze doszedłem do wniosku, że najlepszym rozwiązaniem jest nie zwracanie w sposób przejściowy idealnego przedmiotu.

Ostatnio przeformułowałem sobie pytanie: czy to naprawdę problem z IoC, czy z. NET framework? Pozbywanie się i tak jest niezręczne. Nie ma żadnego sensownego celu funkcjonalnego, tylko technicznego. Więc to bardziej kwestia RAM, z którą musimy się uporać, niż kwestia MKOl.

To, co lubię w DI, to to, że może poprosić o umowę zapewniającą mi funkcjonalność, bez konieczności zawracania sobie głowy szczegółami technicznymi. Nie jestem właścicielem. Nie wiadomo, w której warstwie jest. Brak wiedzy o tym, jakie technologie są wymagane do realizacji zamówienia, brak obaw o żywotność. Mój kod wygląda ładnie i czysto i jest wysoce testowalny. Mogę realizować obowiązki w warstwach, do których należą.

Tak długo, jak my deweloperzy musimy martwić się o pozbycie (czy to się kiedyś zmieni?) Postaram się wstrzyknąć jak najmniej przedmiotów jednorazowego użytku. 1. Staram się, aby obiekt nie był możliwy do zidentyfikowania, na przykład nie utrzymując obiektów jednorazowych na poziomie klasy, ale w mniejszym zakresie. 2. Staram się, aby obiekt był wielokrotnego użytku, aby można było zastosować inny menedżer życia.

Jeśli nie jest to wykonalne, używam fabryki, aby wskazać, że użytkownik zleceniodawca jest właścicielem i powinien wziąć za nią odpowiedzialność.

Jest jedno zastrzeżenie: zmiana wykonawcy umowy z jednorazowego użytku na jednorazowy będzie zmianą zrywającą. W tym czasie interfejs nie będzie już zarejestrowany, ale interfejs do fabryki. Ale myślę, że dotyczy to również innych scenariuszy. Zapomnienie o użyciu kontenera dziecięcego spowoduje od tego momentu problemy z pamięcią. Podejście fabryczne spowoduje wyjątek IOC resolve.

Niektóre przykładowy kod:

using System;
using Microsoft.Practices.Unity;

namespace Test
{
    // Unity configuration
    public class ConfigurationExtension : UnityContainerExtension
    {
        protected override void Initialize()
        {
            // Container.RegisterType<IDataService, DataService>(); Use factory instead
            Container.RegisterType<IInjectionFactory<IDataService>, InjectionFactory<IDataService, DataService>>();
        }
    }

    #region General utility layer

    public interface IInjectionFactory<out T>
        where T : class
    {
        T Create();
    }

    public class InjectionFactory<T2, T1> : IInjectionFactory<T2>
        where T1 : T2
        where T2 : class

    {
        private readonly IUnityContainer _iocContainer;

        public InjectionFactory(IUnityContainer iocContainer)
        {
            _iocContainer = iocContainer;
        }

        public T2 Create()
        {
            return _iocContainer.Resolve<T1>();
        }
    }

    #endregion

    #region data layer

    public class DataService : IDataService, IDisposable
    {
        public object LoadData()
        {
            return "Test data";
        }

        protected virtual void Dispose(bool disposing)
        {
            if (disposing)
            {
                /* Dispose stuff */
            }
        }

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }
    }

    #endregion

    #region domain layer

    public interface IDataService
    {
        object LoadData();
    }

    public class DomainService
    {
        private readonly IInjectionFactory<IDataService> _dataServiceFactory;

        public DomainService(IInjectionFactory<IDataService> dataServiceFactory)
        {
            _dataServiceFactory = dataServiceFactory;
        }

        public object GetData()
        {
            var dataService = _dataServiceFactory.Create();
            try
            {
                return dataService.LoadData();
            }
            finally
            {
                var disposableDataService = dataService as IDisposable;
                if (disposableDataService != null)
                {
                    disposableDataService.Dispose();
                }
            }
        }
    }

    #endregion
}

Myślę, że ogólnie najlepszym rozwiązaniem jest po prostu nie pozbywanie się czegoś, co zostało wstrzyknięte; trzeba założyć, że wtryskiwacz dokonuje alokacji i dealokacji.

To zależy od struktury DI. Niektóre struktury pozwalają określić, czy dana instancja ma być współdzielona (zawsze przy użyciu tego samego odniesienia) dla każdej wprowadzanej zależności. W takim przypadku najprawdopodobniej nie chcesz się pozbyć.

Jeśli możesz określić, że chcesz wstrzyknąć unikalną instancję, to będziesz chciał ją usunąć (ponieważ została ona specjalnie skonstruowana dla Ciebie). Nie znam się na Unity - trzeba by sprawdzić w dokumentach jak to działa. To część atrybutu z MEF i niektórych innych próbowałem, choć.

Umieszczenie fasady przed pojemnikiem może rozwiązać ten problem. Ponadto możesz go rozszerzyć, aby śledzić bardziej bogaty cykl życia, taki jak przestoje i starty usług lub przejścia Stanów usług hostingowych.

Mój kontener ma tendencję do życia w IExtension, który implementuje interfejs IServiceLocator. Jest to fasada dla jedności i pozwala na łatwy dostęp do usług WCf. Dodatkowo mam dostęp do wydarzeń serwisowych z bazy ServiceHostBase.

Kod, z którym skończysz, będzie próbował aby sprawdzić, czy jakikolwiek singleton Zarejestrowany lub jakikolwiek stworzony typ implementuje którykolwiek z interfejsów, które fasada śledzi.

Nadal nie pozwala na pozbycie się w odpowiednim czasie, ponieważ jesteś związany z tymi wydarzeniami, ale trochę pomaga.

Jeśli chcesz pozbyć się w odpowiednim czasie (aka, teraz v. s. po wyłączeniu usługi). Musisz wiedzieć, że przedmiot, który otrzymujesz, jest jednorazowy, jest częścią logiki biznesowej, aby go pozbyć, więc IDisposable powinien być częścią interfejsu obiekt. I pewnie powinna być weryfikacja oczekiwań związanych z wywołaniem metody zbycia.

W ramach Unity są dwa sposoby rejestracji klas wtryskiwanych: jako singletony (otrzymujesz zawsze tę samą instancję klasy, gdy ją rozwiązujesz), lub takie, jak otrzymujesz nową instancję klasy przy każdej rozdzielczości.

W późniejszym przypadku masz obowiązek usunięcia rozwiązanej instancji, gdy jej nie potrzebujesz (co jest całkiem rozsądnym podejściem). Z drugiej strony, gdy pozbywasz się kontenera (klasy, która obsługuje rozdzielczości obiektów), wszystkie obiekty singleton są również automatycznie usuwane.

Dlatego najwyraźniej nie ma problemów z wtryskiwanymi obiektami jednorazowego użytku z Unity framework. Nie znam się na innych frameworkach, ale przypuszczam, że tak długo, jak Framework dependency injection jest wystarczająco solidny, na pewno radzi sobie z tym problemem w taki czy inny sposób.