在 WPF 之外使用 Freezable 类的任何“陷阱”？答案

【问题标题】：Any "Gotchas" with using Freezable class outside of WPF?在 WPF 之外使用 Freezable 类的任何“陷阱”？
【发布时间】：2009-12-23 18:55:53
【问题描述】：

我一直在阅读并发方面的内容，并从更“线程安全”的角度来看待事物。 WPF（或者实际上是 System.Windows.Freezable 和其他）有一个可冻结的类，它可以提供“冰棒不可变”。有没有人尝试在 WPF/Silverlight 之外使用它，使用它会更好，还是自己滚动/使用别人的更好？我知道那里有一些不错的。

【问题讨论】：

标签： c# immutability freezable

【解决方案1】：

您不应在 WPF 之外的 System.Windows 中使用 Freezable 类型。

这样做的原因是您创建了对 WindowBase.dll（或定义 Freezable 的位置）的依赖项。如果没有直接访问 UI，那么“模型项目”中不应存在这样的引用。

但是，您可以轻松编写自己的 Freezable 基类。

我在一个应用程序中使用了以下接口，我想创建需要复杂初始化的线程安全对象（它是循环引用）：

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

    void Freeze();
}

注意 CanFreeze 属性：我决定使用它是因为我想在冻结之前验证 Freezables - 我认为不给客户这样做的机会并不好。

Freezables 的概念是 IMO 的一个好主意，它丰富了多线程应用程序中的工具调色板。

【讨论】：

【解决方案2】：

您可以在任何需要的地方随意使用 Freezable 和其他调度程序/依赖项对象。引用 WindowsBase.dll 与将 GDI32.DLL 加载到无头服务器程序中没有什么不同（因为它们都这样做并且必须这样做）。您唯一需要考虑的是 DispatcherObject 是面向 Windows 消息循环的，并且提供的基础设施对您的益处微乎其微，除非您的代码是事件驱动的并且您的对象驻留在具有 Dispatcher 事件循环的线程上。但是，如果是这样，您可以通过在 DispatcherObject 派生类中使用线程亲和性包装本机对象来获得显着的设计清晰度和灵活性（我已经使用 ESENT 做到了这一点）。这一切都取决于您愿意在多大程度上跳出框框思考。

【讨论】：