Comment conciliez-vous IDisposable et le Cio?

AutoFac poignées en autorisant la création d'un conteneur imbriqué. Lorsque le conteneur est fini avec, automatiquement, il dispose de tous les IDisposable objets. Plus ici.

.. Que vous avez à résoudre des services, Autofac pistes jetables (IDisposable) des composants qui ne sont pas résolus. À la fin de l'unité de travail, vous disposez de la durée de vie de la portée et de l'Autofac permettra de nettoyer automatiquement/débarrasser de l'résolu services.

Ce a me laisse perplexe souvent. Si pas heureux à ce sujet, je suis toujours à la conclusion que jamais de retour d'un IDisposable objet dans un transitoire de la façon qui était le mieux.

Récemment, j'ai reformulé la question pour moi-même: Est-ce vraiment un Cio problème, ou une .net framework problème? L'élimination est difficile de toute façon. Il n'a pas de sens objectif fonctionnel, seulement technique. Il est donc plus une question cadre que nous avons à traiter avec, que du Cio problème.

Ce que j'aime à propos de DI est ce que je peux demander un contrat de m'offrir des fonctionnalités, sans avoir à se soucier des détails techniques. Je ne suis pas le propriétaire. Aucune connaissance de la couche sur laquelle il est en. Pas de connaissances concernant les technologies qui sont nécessaires pour remplir le contrat, pas de soucis à propos de la durée de vie. Mon code a l'air sympa et propre, et il est très testable. Je peux mettre en œuvre des responsabilités dans les couches où ils appartiennent.

Donc si il y a une exception à cette règle, ce qui ne m'obligent à organiser la vie, faisons en sorte que cette exception. Si je l'aime ou pas. Si l'objet qui implémente l'interface m'oblige à mettre au rebut, je veux savoir à ce sujet depuis que je suis déclenchée à utiliser l'objet de la plus courte possible. Un truc de le résoudre à l'aide d'un conteneur enfant qui est disposé quelques temps plus tard pourrait encore me causer de garder l'objet en vie plus longtemps que je ne l'. Le permis de durée de vie de l'objet est déterminé lors de l'enregistrement de l'objet. Pas par la fonctionnalité qui crée un conteneur enfant et tient pour une certaine période.

Tant et aussi longtemps que nous, développeurs, besoin de s'inquiéter à propos de l'élimination (va jamais changer?) Je vais essayer d'injecter quelques transitoire jetables d'objets que possible.
1. J'essaie de faire de l'objet n'est pas IDisposable, par exemple, ne pas garder les objets jetables sur le niveau de la classe, mais dans une moindre portée.
2. J'essaie de faire l'objet réutilisables ainsi qu'une durée de vie de manager peut être appliquée.

Si cela n'est pas possible, j'utilise une usine pour indiquer que l'utilisateur de l'injection de contrat est propriétaire et doit en assumer la responsabilité.

Il y a un problème: la modification d'un contrat de maître d'œuvre de non-jetables à usage unique sera d'une modification de rupture. À cette époque, l'interface ne sera plus enregistré, mais l'interface de l'usine. Mais je pense que cela s'applique à d'autres scénario est ainsi. Oublier d'utiliser un conteneur enfant sera à partir de ce moment, donner des problèmes de mémoire. L'usine approche entraîne un Cio résoudre exception.

Un exemple de code:

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
}

Cela dépend de la DI-cadre. Certains cadres vous permettent de spécifier si vous souhaitez une instance partagée (en utilisant toujours la même référence) pour chaque dépendance injecté. Dans ce cas, vous probablement ne voulez pas pour jeter.

Si vous pouvez préciser que vous souhaitez une instance unique injecté, alors vous voulez vous débarrasser (depuis qu'il a été construit pour vous en particulier). Je ne suis pas aussi familier avec l'Unité, tu devrais vérifier les docs quant à la façon de faire ce travail là. C'est une partie de l'attribut avec le MEF et quelques autres que j'ai essayé, pourtant.

Dans le cadre de l'Unité, il y a deux façons d'enregistrer les injecté classes: comme des singletons (vous obtenez toujours la même instance de la classe lorsque vous le résoudre), ou comme vous obtenez une nouvelle instance de la classe sur chaque résolution.

Dans ce dernier cas, vous avez la responsabilité de l'élimination de l'résolu instance une fois que vous n'en avez pas besoin (ce qui est tout à fait raisonnable). D'autre part, lorsque vous mettez le contenant (la classe qui gère objet de résolutions), tous les objets singleton sont automatiquement éliminés en tant que bien.

Par conséquent, il n'y a apparemment pas de problèmes d'injection jetable objets avec l'Unité du cadre. Je ne sais pas pour les autres cadres, mais je suppose que tant qu'une injection de dépendance cadre est assez solide, elle pour s'assurer que les poignées de cette question d'une façon ou d'une autre.