I recently wrote a post about composing a UI based on discrete behaviors. I thought maybe I should explain a bit more about the problem that led me to this idea.
Mike Wagg, Zubair Khan and I were tasked with developing a rather complex UI using ASP.NET Web Forms (the company had a suite of existing custom controls, so unfortunately MVC was not an option). We started-off using a Model View Presenter (MVP) pattern, but found that our presenters became overloaded with state management responsibilities. So we introduced a Presentation Model to handle the state and behavior of the View.
The ASP.NET page life cycle never failed to cause us grief. We attempted to abstract away the life cycle using a combination of a View, Presentation Model and backing Controller. The page populated the Presentation Model on Load and bound back to it on PreRender. Any state changes that occurred during the page life cycle was applied to the Presentation Model. The Controller’s responsibility was to receive events from the View, call out to services and pass data to the Presentation Model.
We found this greatly simplified things, as we didn’t have to worry about the changing state of the View throughout the page life cycle. We simply updated the Presentation Model and the View submissively bound to it at the end of the life cycle. We could also effectively test the entire process, as we didn’t rely on the page to manage state changes.
The only downside to the Presentation Model was that we had to change the code in order to accommodate new behavior. This violates the Open/Closed Principal (OCP) and increased the risk of breaking existing functionality. That led me to investigate the discrete behaviors approach that I blogged about.
Another problem we faced was getting the presentation components to talk to each other. We were using the View as the messaging bus, but this led to a lot of code that looked like parentView.childView.DoSomething(). This was very brittle, so we created an Event Hub that acted as a central messaging bus that any of the presentation components could publish/subscribe to.
We now feel we have this complex UI project under control. Mike is currently writing a series of posts that go into further details on the Presentation Model and Event Hub approaches. We learned a lot from this project and I hope this can help someone else who is creating a complex UI in a stateless web environment.