ASP.NET - Separation of concerns

Question

Imagine the following scenario - we have Page1 which contains controls Control A and Control B.

Say Control A has a button, and on the click of this button we want Control B to react. But we want to do this in an abstract fashion, i.e. we can't have Control B knowing anything about Control A, and vice versa.

That way we can develop these controls in isolation, and drive them by unit-testing.

Now, I thought I had the solution, just want to know what you guys think of it.

On Control A's button click, I put a 'message' on the Session, i.e. Session["MESSAGES"] = "ControlA_Click".

In Page1, on the Page_LoadComplete(), I put a call to ProcessMessages, which looks like this:

      List<Message> messages = SessionMessages.GetMessageList(Page);
  foreach(Message m in messages)
  {
   //Get Controls
   ControlA controlA = FindControl("controlA") as ControlA;
   controlA .ProcessMessage(m);

   ControlB controlB = FindControl("controlB") as ControlB;
            controlB.ProcessMessage(m);
      }

in ControlB's ProcessMessage() method, we can react to the messages that ControlB is interested in, like so:

    if (m.MessageName == SessionMessages.C_MESSAGE_SEARCH)
{
 this.Visible = true;
}

To me, this seems to work. It allows us to develop these controls completely separately from eachother, while still allowing for inter-control-communication at an abstract level.

The only thing I can think of that might bring this crashing down is perhaps the ASP.NET life-cycle in relation to Pages and User Controls. The way I figure it though is that ALL events should have been processed on the controls before Page_LoadComplete() is called on the owning Page.

Thoughts?

Answer 1

an interesting abuse of the session...

you could also have the message queue belong to the hosting page instead

i would recommend that instead you have the hosting page do something to the control in response to the message, rather than making the control be 'smart' - there is really no need for a button to be 'smart'

Answer 2

1. Control A should raise an event
2. The page housing the controls subscribes to the event & then calls the appropriate method in the other control
3. Control B should process the message()

Answer 3

Check out the Managed Extensibility Framework Contrib project. They have just a sample website that is just what you want.

Answer 4

Isn't this what databinding is for? Control A responds to an event that updates the model and then calls databind on its dependencies.

If you want to make a messaging system, design it to the publisher and subscriber do not need to know about each other, only the message itself. Create an interface something like:

public interface IHandle<T> where T:IMessage
{
     void Process(T message)
}

You will need a method of discovering which controls implement it and build a map of messagetype->handlers, have a look at the way the main DI frameworks handle property injection to ASP .NET controls to see how you can achieve this. You can then use a single SendMessage method which is responsible for dispatching the message to all controls that can handle that message. It's more common see this sort of pattern in forms UI.

Answer 5

There are some problems with this approach like:
- The 'events' are not verified at compile (you can easily mistype an event name and find out about this at runtime or worst)
- Filling session with communication stuff
- You need to put control names as strings - If there are more than one control that is a subscriber to these event can become difficult to control
- When parameters will need to be send between controls the solution will become more difficult to manage

A better approach is to use the build in event mechanism by declaring events on the controls:

public event EventHandler SpecialClick;

Each control that needs to do something will subscribe to this event

controlA.SpecialClick += new EventHandler(controlA_SpecialClick)

using the normal dot.net events.

Answer 6

As Briggie alludes to - this is exactly what Model-View Presenter is all about. Here's an article around MVP in .NET, if you want to roll your own.

Ideally you want to look at the MVC framework as an example of what you can do when you separate out everything.

What I normally do is have the button click event raise a domain-specific event, something like:

private void ControlA_OnClick(..)
{
  if(LoginRequested != null)
    LoginRequested(this, loginObj);
}

That way it makes it clear why someone would click the button and drives home the separation.

Answer 7

What you have is pretty much an EventBroker. I don't think Session is the appropiate place for this, as it's not necessary to live across requests. HttpContext might work, but unless I wanted the message bus to be shared between IHttpModules and IHttpHandlers, I'd probably just either use a base Page class that custom controls can cast their Page instance to:

interface IEventBroker {
 void Send(Message m);
}

class ControlA {
  void MyButton_Click(object sender, EventArgs e) {
     var eb = this.Page as IEventBroker;
     if (eb != null) eb.Send(new Message());
  }
}

or give the controls a reference to the EventBroker - in which case I'd probably make the EventBroker itself a control and give the ID to each control so that they could use Page.FindControl.