C# Best Practices – Subscribe/Publish Model in Web-based Applications

design-patternsobject-oriented-design

I was recently exposed to a desktop application that uses an publish/subscribe model to handle commands, events, etc. I can't seem to find any good examples of using this in a web application, so I wonder if I am off base in trying to use this for web based development (on the server side)? I'm using asp.net c#.

My main question in regards to the design is:
When using a publish/subscribe model, is it better to have generic commands/events that pass no parameters and then have the subscribers look at static context objects that contain the data relevant to the event? Or is it better to create custom arguments for every event that contain data related to the event?

The whole concept of a global container seems so convenient but at the same time seems to break encapsulation.

Any thoughts or best practices from anyone who has implemented this type of model in a web based application? Even suggestions on this model out of the scope of my question are appreciated.

Best Answer

For patterns (observer pattern, publish/subscribe, visitor pattern) where there is a single entity talking to or dealing with multiple entities the communication has what i call it language problem.

There is something similar i had answered which i recommend you to read Observer pattern; knowing *what* changed?

Basically, if you only give single argument or no arguments which means events are triggered and received as you want but they don't quite convey much. It works fine for many trivial example. On the other side if you keep too much information diverse for each module - then definitely you are creating something (as you call it a container) is only a dumping bags. Even for a moment if we keep encapsulation violation arguments away for a moment, dumping bags are not good. For the first part, if you have one more customer and if the container gets one more information is added all other customers now will have to ignore one more field (and recompile themselves)

Part of the problem really is, that while we typically generalize the observers (i.e. different concrete objects as observer and implement observe() or notify() method) but it is equally important that the notification that needs to be given itself is a matter of abstraction. We must ask - what should i notify? and even more what must i not notify?

Take a real world notifiers to understand this:

1. First of that class is broadcast type messages
* a notification at airport notifies about: arrived departed flights and their times.
* a stock market bill board notifies about: updates on various stocks

The first thing to understand that what gets notified is far more stable and very easily understandable, and hence, attaching any number receiver will not ever create a problem. The metadata is well defined and even if it has to change, it is likely that most observer will get benefited from it.

So really speaking language problem doesn't exists in broadcast type notifications.

2. The multicast or unicast scenario where there messages specific to obsever

Any typical newsletter or rss feed or email are rather personal, there is too and from fields that get the message to places. Here the message can be anything - so for all practical purposes, the message transmission doesn't typically have any single format that can hold all information - this is another extreme where to which a container can evolve to. As in the cases of emails for example, the metadata is again standardized but much meaningful information is in the body and it is upto the end observer/reader to interpret this. the language problem does exists here but channels (in our case the API which carries information) must be freed from interpreting this. Let the source somehow create a blob of information and let the observer know what to do with the blob.

So in essence, what you really need to do is to model the notification - what is truly the message content which needs to be black-boxed. the essence of the answer i gave in above link is that you may create a sort of generic name-value pairs or any general encoding of messages and pass on. It can even be something like void* of C. But that exercise is must. On the other hand, find what is the metadata (such as source, timestamps, etc.). These fields can be visible to all message readers.

One last thing to note is, be critical to what is the responsibility of the source/publisher and what is not avoid customizations, extensions to the definition or role of publisher for specific customers. This is the single most source of digression in most such cases. Avoid till you come to a point of loosing salary! :)

Doing all this will force you to put more effort but save you from the technical debt of evolving into a huge (depending on your scale) garbage bag type container and most people cannot figure out why these things are there.

Related Solutions

Web Application Design – Best Practices for Server Side Layering

Warning long, rambling answer follows and I'm not really using 1/2 of the formal terminology that I should be (but that's OK, because someone will correct me!):

No Golden Bullet

I'll start by saying that I think each software architecture should be designed for the problem at hand. There is no golden bullet, silver hammer or one solution that fits all cases.

Overall strategy

Is to:

Decouple your components
Code to interfaces
Generally think about the separation of concerns
Think about who is calling your code for what purpose

Why are there patterns?

Design patterns (and therefore frameworks around them) emerge because they solve certain common problems.

However, a mistake that I think many Java developers are guilty of is to over engineer architectures, applying patterns left right and centre. They think about all sorts of exotic "What If?" scenarios. My advice is that although there are common patterns out there, don't just blindly apply them, make sure you've got solid reasoning for doing so.

Examples

1.) People have used MVC for years because it gives you flexibility to change either the model, view or controller without impacting each other (unless you want them to). So for example if I want to:

Change my View technology from JSP to JSF I shouldn't have to change my 'Dog' Model
Add a legs field to my Dog Model, I don't automatically have to add that legs field to my list of Dogs View, or change my Controller in order for a user to travel from list of Dogs View to a detailed View of one Dog.

2.) One of the reasons why Services have become popular because of the rise of multiple clients. So for example if I want to have a Java Swing client and a JSP client that both list the big Dogs in the system they can both call the same DogShelterService method List<Dog> getBigDogs();

Conclusion

There are lots more examples of patterns and why they came about (I suspect someone will give better examples than I did). I find using a BDD, TDD/ATDD approach (at least in terms of your thinking) helps clarify the design and where you might want to go for a formal design patterns and where simple code will do just nicely.

Best Design for Windows Forms with Common Functionality

I don't know why you need static controls. Maybe you know something I don't. I've used a lot of visual inheritance but I've never seen static controls to be necessary. If you have a common treeview control, let every form instance have its own instance of the control, and share a single instance of the data bound to the treeviews.
Sharing control state (as opposed to data) between forms is also an unusual requirement. Are you sure FormB really needs to know about the state of buttons on FormA?Consider the MVP or MVC designs. Think of each form as a dumb "view" that knows nothing about the other views or even the application itself. Supervise each view with a smart presenter/controller. If it makes sense, a single presenter can supervise several views. Associate a state object with each view. If you have some some state which needs to be shared between views, let the presenter(s) mediate this (and consider databinding - see below).
Agreed, Visual Studio will give you headaches. When considering form or usercontrol inheritance, you need to carefully weigh the benefits against the potential (and probable) cost of wrestling with the form designer's frustrating quirks and limitations. I suggest keeping form inheritance to a minimum - use it only when the payoff is high. Keep in mind that, as an alternative to subclassing, you can create common "base" form and simply instantiate it once for each would-be "child" and then customize it on-the-fly. This makes sense when differences between each version of the form are minor compared to the shared aspects. (IOW: complex base form, only-slighty-more-complex child forms)

Do make use of usercontrols when it helps you prevent significant duplication of UI development. Consider usercontrol inheritance but apply the same considerations as for form inheritance.

I think the most important advice I can offer is, if you don't currently employ some form of the view/controller pattern, I strongly encourage you to start doing so. It forces you to learn and appreciate the benefits of loose-couping and layer separation.

response to your update

Which layer should store stuff like, the last pressed button, so that I can keep it highlighted for the user...

You can share state between views much like you would share state between a presenter and its view. Create a special class SharedViewState. For simplicity you can make it a singleton, or you can instantiate it in the main presenter and pass it to all views (via their presenters) from there. When the state is associated with controls, use data binding where possible. Most Control properties can be data-bound. For example the BackColor property of a Button could be bound to a property of your SharedViewState class. If you do this binding on all forms which have identical buttons, you can highlight Button1 on all forms just by setting SharedViewState.Button1BackColor = someColor.

If you aren't familiar with WinForms databinding, hit MSDN and do some reading. It's not difficult. Learn about INotifyPropertyChanged and you're halfway there.

Here's a typical implementation of a viewstate class with the Button1BackColor property as an example:

public class SharedViewState : INotifyPropertyChanged
{
    // boilerplate INotifyPropertyChanged stuff
    public event PropertyChangedEventHandler PropertyChanged;
    protected void NotifyPropertyChanged(string info)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(info));
        }
    }

    // example of a property for data-binding
    private Color button1BackColor;
    public Color Button1BackColor
    {
        get { return button1BackColor; }
        set
        {
            if (value != button1BackColor)
            {
                button1BackColor = value;
                NotifyPropertyChanged("Button1BackColor");
            }
        }
    }
}

Best Answer

Related Solutions

Web Application Design – Best Practices for Server Side Layering

Best Design for Windows Forms with Common Functionality

Related Topic