在WPF之外使用Freezable类有什么需要注意的地方吗？

Question

在WPF之外使用Freezable类有什么需要注意的地方吗？

3

我一直在学习并发性，并从更“线程安全”的角度看待事物。WPF（实际上是System.Windows.Freezable和其他类）有一个可冻结类，可以提供“冰棒不变性”。有没有人尝试在WPF / Silverlight之外使用它？使用这个类会更好，还是自己编写/使用别人的代码？我知道有一些很好的代码可用。

- Bless Yahu

2个回答

1

在需要的地方随意使用Freezable和其他调度程序/依赖对象。引用WindowsBase.dll与将GDI32.DLL加载到无头服务器程序中没有任何区别（因为它们都这样做并且必须这样做）。您唯一需要考虑的是，DispatcherObject围绕Windows消息循环定向，并提供基础设施，除非您的代码是事件驱动的并且您的对象驻留在具有Dispatcher事件循环的线程上，否则对您的帮助将最小化。但如果是这样，您可以通过将具有线程亲和性的本机对象包装在DispatcherObject派生类中（我已经在ESENT中以极大的效果完成了此操作）获得实质性的设计清晰度和灵活性。这完全取决于您愿意思考多少超出常规。

- Joshua A. Schaeffer

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Matthias · Accepted Answer

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

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

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

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

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

    void Freeze();
}

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

Freezables的概念在我看来是一个很好的想法，它丰富了多线程应用程序的工具组合。