Des "Gotchas" avec l'utilisation de la classe Freezable en dehors de WPF?

Question

J'ai lu sur la concurrence, et en regardant les choses d'un point de vue plus "thread safe". WPF (ou en fait System.Windows.Freezable et autres) a une classe freezable, qui peut donner "l'immutablité popsicle". Est-ce que quelqu'un a essayé d'utiliser ceci en dehors de WPF/Silverlight et serait-il préférable de l'utiliser, ou de rouler le vôtre/d'utiliser quelqu'un d'autre? Je sais qu'il y en a quelques bonnes.

Answer 1

Vous ne devez pas utiliser le type Freezable dans System.Windows en dehors du WPF.

La raison en est que vous créez une dépendance à WindowBase.dll (ou lorsque Freezable est défini). Et une telle référence ne devrait pas exister dans les «projets modèles» sans accès direct à l'interface utilisateur. Cependant, vous pouvez facilement coder votre propre classe de base Freezable.

J'utilise l'interface suivante dans une application où je voulais créer des objets thread-safe qui exigeaient l'initiation compliquée (il était des références circulaires):

public interface IFreezable 
{ 
    bool CanFreeze 
    { 
     get; 
    } 
    bool IsFrozen 
    { 
     get; 
    } 

    void Freeze(); 
} 

Notez la propriété CanFreeze: j'ai décidé de l'utiliser comme Je voulais valider les Freezables avant de geler - et ne pas donner au client une chance de le faire n'est pas bon à mon avis.

Le concept de Freezables est une bonne idée qui enrichit la palette d'outils dans les applications multi-thread.

Answer 2

N'hésitez pas à utiliser Freezable et d'autres objets expéditeur/dépendance où vous en ressentez le besoin. Referencing WindowsBase.dll n'est pas différent de chargement GDI32.DLL dans un programme de serveur sans tête (comme ils le font tous et doivent). La seule chose que vous devez prendre en compte est que DispatcherObject est orienté autour de la boucle de messages Windows et fournit une infrastructure qui vous sera très utile à moins que votre code ne soit piloté par des événements et que vos objets résident sur des threads avec des boucles d'événements Dispatcher. Mais si c'est le cas, vous pouvez obtenir une clarté et une flexibilité de conception substantielles en enveloppant les objets natifs avec une affinité de thread dans les dérivés de DispatcherObject (je l'ai fait avec ESENT). Tout dépend de la distance à l'extérieur de la boîte que vous êtes prêt à penser.