Design patterns for event-driven logic

Question

I'm developing a desktop application which depends on the XML data it receives from a server. There are several files, needed to be downloaded at different time.

A number of data structures is populated with parsed data. The correspondence between files and data structures isn't 1-to-1, as a matter of fact may be rather complicated.

Application states and transitions between states depends on contents (and their availability at the moment) of those pieces of downloaded information.

Obscure spagetti code handles all the download events, and interdependences.

I've been working for a while on some pattern to work with it in a more uniform way, but thought that the developer community has already figured out the most appropriate practices and patterns. Does anyone know of any?

Answer 1

Probably one of the best known design patterns for event driven systems is the observer pattern.

Answer 2

What about Model View Controller (MVC)?

Answer 3

I have been working extensively with the Model-View-ViewModel pattern for a while now and I highly recommend it. While most articles about it around the web link it firmly with WPF, there's no reason to not use it with other technologies. I've used it against a web service, WPF client and command line (three "Views" sharing lower layers).

Here's my quick and dirty description: The pattern consists of three layers (from top down): View (usually GUI, but really any external interface), ViewModel (containing business logic and working set of data) and Model (domain objects etc). Each layer communicates directly with the layer(s) below and fires events for layer(s) above.

In .Net land the pattern relies heavily on the INotifyPropertyChanged interface. When your data structures in the Model change, they could fire an event. The ViewModel can update its state (the application state) in response and fire its events. The View can then update to display the new app state.

Here's a decent article: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Once again, that article is WPF centric.

I hope this answer was at the right level for you. If not, some more information about the problem could be useful. You're not talking about semaphores, queues and threads are you?

Answer 4

Application states and transitions between states depends on contents (and their availability at the moment) of those pieces of downloaded information.

Looks like you have a need for usage of tiered patterns. What I mean by that is in the example you stated above is the usage of a strategy pattern sitting on top of a state pattern.

Answer 5

When you have states you will definitely need State Pattern. When you have complex rules regarding state transitions and different BL connected to this states this is the best way to go.First draw state diagram, and after that it is easy to write needed classes.

I must also agree with John for Observer patter, you could use it to make needed dependency inversion, and handle state transitions easily.

In your case you can put all BL into State Classes and process when system hits that State, you will have code separation and no spaghetti code... Code will follow and execute BL according to state transitions.