Как Вы согласовываете IDisposable и МОК?

Я думаю, что в целом лучший подход - просто не утилизировать то, что было введено; вы должны предположить, что инжектор выполняет распределение и освобождение.

This depends on the DI framework. Some frameworks allow you to specify whether you want a shared instance (always using the same reference) for every dependency injected. In this case, you most likely do not want to dispose.

If you can specify that you want a unique instance injected, then you will want to dispose (since it was being constructed for you specifically). I'm not as familiar with Unity, though - you'd have to check the docs as to how to make this work there. It's part of the attribute with MEF and some others I've tried, though.

Вы определенно не хотите вызывать Dispose () для объекта, который был внедрен в ваш класс. Вы не можете сделать предположение, что вы единственный потребитель. Лучше всего поместить свой неуправляемый объект в какой-нибудь управляемый интерфейс:

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

Это просто пример, я бы использовал File.ReadAllText (path), если бы я пытался прочитать текстовый файл в строке.

Другой подход состоит в том, чтобы внедрить фабрику и самостоятельно управлять объектом:

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

В фреймворке Unity есть два способа зарегистрировать внедренные классы: как одиночные (вы всегда получаете один и тот же экземпляр класса при его разрешении) или такой, как вы получаете новый экземпляр класса для каждого разрешения.

В последнем случае вы несете ответственность за удаление разрешенного экземпляра, если он вам не нужен (что является вполне разумным подходом). С другой стороны, когда вы удаляете контейнер (класс, который обрабатывает разрешения объектов), все одноэлементные объекты также автоматически удаляются.

Таким образом, очевидно, что нет проблем с внедренными одноразовыми объектами в среде Unity. Я не знаю других фреймворков, но полагаю, что, пока фреймворк внедрения зависимостей достаточно прочен, он наверняка так или иначе решает эту проблему.

Помещение фасада перед контейнером также может решить эту проблему. Кроме того, вы можете расширить его для отслеживания более богатого жизненного цикла, например, отключения и запуска сервисов или переходов состояния ServiceHost.

Мой контейнер обычно живет в расширении IExtension, которое реализует интерфейс IServiceLocator. Это фасад для единства, и он обеспечивает легкий доступ в WCf сервисах. Плюс у меня есть доступ к событиям сервиса из ServiceHostBase.

Код, который вы получите в итоге, будет пытаться проверить, реализует ли любой зарегистрированный синглтон или любой созданный тип любой из интерфейсов, которые отслеживает фасад.

Это все еще не позволяет своевременно избавляться, поскольку вы привязаны к этим событиям, но это немного помогает.

Если вы хотите утилизировать своевременно (например, сейчас, а не после закрытия службы). Вам нужно знать, что полученный вами элемент является одноразовым, это часть бизнес-логики по его утилизации, поэтому IDisposable должен быть частью интерфейса объекта. И, вероятно, должна быть проверка ожиданий, связанных с вызовом метода dispose.