开发者

Any "Gotchas" with using Freezable class outside of WPF?

开发者 https://www.devze.com 2022-12-15 04:59 出处:网络
I\'ve been reading up on concurrency, and looking at things from a more \"thread safe\" point of view.WPF (or actually System.Windows.Freezable and others) has a freezable class, which can give \"pops

I've been reading up on concurrency, and looking at things from a more "thread safe" point of view. WPF (or actually System.Windows.Freezable and others) has a freezable class, which can give "popsicle immutablity". Has anyone tried using this outsid开发者_如何学Goe of WPF/Silverlight and would it be better to use this, or roll your own/use someone else's? I know there's a few good ones out there.


You should not use the Freezable type in System.Windows outside the WPF.

The reason for that is that you create a dependency to WindowBase.dll (or where Freezable is defined). And such a reference should not exist in "model projects" without direct access to the UI.

However, you can easily code your own Freezable base class.

I used the following interface in an application where I wanted to create thread-safe objects which required complicated initiation (it were circular references):

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

    void Freeze();
}

Note the CanFreeze property: I decided to use it as I wanted to validate the Freezables before freezing - and not giving the client a chance to do so is not good in my opinion.

The concept of Freezables is IMO a nice idea which enriches the palette of tools in multi-threaded applications.


Feel free to use Freezable and other dispatcher/dependency objects wherever you feel the need. Referencing WindowsBase.dll is no different from loading GDI32.DLL into a headless server program (as they all do and must). The only thing you need to consider is that DispatcherObject is oriented around the Windows message loop and provides infrastructure that will be of minimal benefit to you unless your code is event-driven and your objects reside on threads with Dispatcher event loops. But if so, you can gain substantial design clarity and flexibility from wrapping native objects with thread affinity inside DispatcherObject derivatives (I have done this to great effect with ESENT). It all just depends how far outside the box you are willing to think.

0

精彩评论

暂无评论...
验证码 换一张
取 消