I've been working on a system that contains many relatively complex user interactions; interactions which require the user to navigate over several forms, entering information and interacting with the system at each one. As it is currently written, the system uses mainly Win32 dialogs, with data shared between dialogs in global variables. A mess. In re-designing the system, we wanted to use Model driven design, and an MVP like pattern for the UI components. Our initial design had model and form classes put into a repository and retrieved by the presenter, which worked ok, but it was too easy to forget to put a component in the repository. Forgetting to put a component in the repository led to runtime errors which could be challenging to track down. Also, with all the forms chained together, the presenter classes wound up being fairly tightly coupled. I wanted a system that made the construction mistakes impossible, and that allowed for de-coupled presenters.
The first challenge was figuring out how the de-coupled presenters would be chained together. The solution I came up with was a super-presenter, which I call the WorkflowManager. Initially, there was a lot of overlap between the presenters and the workflow manager. In fact, it was not at all clear where the divisions should be between the workflow manager and the presenter, or between the presenter and the form. Similarly, we have user workflows that involve multiple selections which the system must iterate over. Here the solution is a special class of model which contains a list of single transaction classes (each of which is itself a model) and the knowledge of how to iterate over the list. By layering the architecture we have been able to keep the classes relatively small and highly cohesive. The tests are all so simple they hardly seem worth doing, but in aggregate they do an excellent job of validating system behavior.
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment