locked
Help deciding on winform, event/action intensive design pattern RRS feed

  • Question

  • Hello - I'm trying to determine the best design pattern for a winform application that's not a standard client/server or presenter/business/data app.  This app performs numerous specialized workstation management functions based on diverse events which it transates into actions.  Because the app started small and simple most of the control code (biz logic) is in the main form (essentially the main form is the controller) but the app has become multifunctional, is growing, and subsequently is more difficult to maintain.  In a nutshell, the app performs single sign on, user proximity detection, battery monitoring, system event monitoring, and performs numerous actions based on events from these subscriber components (usb device, window message hooks, wmi, TCP sockets) as well as commands received via the network.  Although classes are used to represent the various  subscriber components they are mostly polled by the UI thread (at any point in time several other winforms may also be present and responding to subscriber component events).  In some cases where numerous events are received in a short period of time (such as window messages)  delegates/events are used which are converted to a homegrown event object and added to a que (generic collection) and subsequently dequeued by a separate, continuously running thread which performs one of many possible actions represented by a switch block currently but will eventually be loaded into a hash table at runtime for scalability.  Essentially there are many events and many possible actions and performance is very important.

    I'm just learning about patterns and am initially drawn towards the MVC Passive View model combined with the Command model but have concerns about both and generally lack confidence in any pattern do to my overall lack of knowledge and experience with them.
    1.) Will the extensive use of delegates and object creation on the fly employed by MVC passive view have a negative performance impact?
    2.) Must each view or model have it's own controller?  It would be ideal for a single controller/service to broker all events and actions (updates to winforms, etc.) especially since there may be multiple threads.  This seams more like a star shaped pattern with a single controller and multiple views and models (multiple observers and subjects).
    3.) Because the app queues actions as well a events for processing by a worker thread it seems to make sense to convert the actions in Command Objects and queue them instead of using pointers in a hash table to one of many action methods in a long switch statement (where the details of the actions currently reside)?

    Apologies for any incorrect use of terminology and concepts.
    Appreciate any help you can provide.
    Thanks,
    jim
    Wednesday, February 4, 2009 4:04 PM

Answers

  • Hi Jim

    Terminology is important when trying to communicate conceptually in this arena. I find that starting with Fowler is almost always the best way to get a feel for how the community is talking about a concept, and what it means. He coined the term "Passive View" as a variation of MVP, where the Presenter replaces the Controller member of the triad. He also has a very good synopsis of many of the major variations on the theme (although I haven't seen him address MVVM yet). The point is that they are all variations on a conceptual theme.

    I also gravitate towards passive view. At best, it leaves you with a UI that is concentrating only on interface gestures and is much more amenable to different presentation technologies (ie, WPF or web); and it leaves you with events that are more easily tested, since they are being controlled by POCOs. The down side is you have a more complicated Presenter.

    To take a stab at some of your questions:
    1) MV(P) in and of itself will not  be a factor in determining whether you have a performance issue that requires optimization. I'm sure you have heard the rule of thumb to design for functionality and maintenance before even assuming that you have a performance issue. If it turns out that you do, you can refactor towards an optimization more effectively. Chances are better than good that you will not have the performance issue you feared, but you'll be better able to address it if you do.
    2) Look up "event broker" or "event aggregator'; again Fowler is your starting point
    3) I'm not sure I understood this one very well, but it does sound like Command objects would be useful.

    Regards,
    Berryl
    • Marked as answer by jimNeocasa Tuesday, February 10, 2009 8:36 PM
    Tuesday, February 10, 2009 7:55 PM

All replies

  • Although, you may want to use the MVC pattern for the UI aspect it doesn't seem to meet your primary goal of managing or responding to many sub systems.

    I have some experience of realtime software so I may have been drawn to the manager/controller pattern because of this.  Here a manager component has responsibility to manage many subsystems.  The manager polls the subsystems to discover the sub systems state and act accordingly.  This can be modified to respond to events.

    I would look at the command and strategy pattern to encapsulate the actions.  The strategy pattern is useful if they may change a lot and there are related groups of algorithms to encapsulate.  It doesn't sound like there are in your example so I would favour the command pattern.

    To answer your other questions;

    1.  Yes, but this is only a concern if the solution has to be relatively realtime.
    2. Generally, controllers and views are closely coupled so yes.
    3. Yes, the command pattern will make your code more readable.  I would also take a look at the GoF pattern book for other patterns that may meet your requirements in this respect.


    Pl mark as answer or helpful if you found this useful
    Tuesday, February 10, 2009 9:06 AM
  • Hi Jim

    Terminology is important when trying to communicate conceptually in this arena. I find that starting with Fowler is almost always the best way to get a feel for how the community is talking about a concept, and what it means. He coined the term "Passive View" as a variation of MVP, where the Presenter replaces the Controller member of the triad. He also has a very good synopsis of many of the major variations on the theme (although I haven't seen him address MVVM yet). The point is that they are all variations on a conceptual theme.

    I also gravitate towards passive view. At best, it leaves you with a UI that is concentrating only on interface gestures and is much more amenable to different presentation technologies (ie, WPF or web); and it leaves you with events that are more easily tested, since they are being controlled by POCOs. The down side is you have a more complicated Presenter.

    To take a stab at some of your questions:
    1) MV(P) in and of itself will not  be a factor in determining whether you have a performance issue that requires optimization. I'm sure you have heard the rule of thumb to design for functionality and maintenance before even assuming that you have a performance issue. If it turns out that you do, you can refactor towards an optimization more effectively. Chances are better than good that you will not have the performance issue you feared, but you'll be better able to address it if you do.
    2) Look up "event broker" or "event aggregator'; again Fowler is your starting point
    3) I'm not sure I understood this one very well, but it does sound like Command objects would be useful.

    Regards,
    Berryl
    • Marked as answer by jimNeocasa Tuesday, February 10, 2009 8:36 PM
    Tuesday, February 10, 2009 7:55 PM
  • Thanks Berryl.  I looked up Fowler's description of Event Aggregator and this sounds lilke the closest match to what I envisioned.  Also, good point about the first focussing on functionality design and address performance after - I started to lose sight.

    G Moore - Command pattern for actions seems like a good fit due to the variation in actions.  Thanks

    Jim

    Tuesday, February 10, 2009 8:41 PM