Question

I have the following bits of code which, in my mind, seem like the bare basics necessary to implement the Observer pattern. Is this standard, or am I doing something wrong?

public class LayoutManager
{
    public CormantTimer Timer { get; set; }
}

protected void Page_Init(object sender, EventArgs e)
{
    LayoutManager.Instance.Timer = RefreshAndCycleTimer;
}

public class CormantRadDock : RadDock, ICormantControl<RadDockSetting>
{
    public CormantRadDock()
    {
        LayoutManager.Instance.Timer.TimerEvent += DoTimerRefreshTick;
    }
}

The CormantRadDock objects are dynamically created. RefreshAndCycleTimer is on Page.

I am worried that, as my project grows larger, there will be a large amount of non-related controls in LayoutManager -- just there to be subscribed to. Is this standard? Should I be doing something different?

Thanks

Was it helpful?

Solution

Don't use events if you want loosely-coupled messaging, use an EventAggragator. Caliburn.Micro has an decent one.

http://devlicio.us/blogs/rob_eisenberg/archive/2011/05/30/caliburn-micro-soup-to-nuts-part-8-the-eventaggregator.aspx

An EventAggregator is a Mediator type pattern that lets publishers and subscribers work through an intermediary, therefore enabling loosely-coupled interaction. Publishers and subscribers do not need to know about each other.

Look for an EventAggregator that uses "Weak Refereneces" to overcome the classic issue with eventing type patterns i.e. GC memory leaks. Caliburn does exactly this.

OTHER TIPS

Use a loosely-coupled eventing mechanism, like the EventAggregator

http://msdn.microsoft.com/en-us/library/ff921122(PandP.20).aspx

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top