Event Oriented Architecture -- Windows Service and Winforms Plugins
Architecting and writing an application can raise many serious interesting design decisions to which one can find many conflicting answers. Typically, each software application requires its own type of architecture, the structure of applications cannot be generalized into one form. Working on some recent projects, I have employed an architecture very similar to the ASP.NET architecture itself. Whoever designed ASP.NET did an incredibly good job and built a system that can be easily extended and manipulated.
I’ve applied similar techniques, as well as other concepts to a recent project and have published some of my findings here. I believe this may be useful to people considering building an application that is rich and not necessarily dependant on a database (a content management system would not fit within this model). For lack of a better term, I am dubbing this model “event oriented architecture”. This model may very well already exist under a different name, but I have not seen it discussed in any classic OOP design books.
An Overview
The system I have been writing had a few very specific requirements. One of the most important requirements was a high-level of expandability and a true abstraction of the data layer. To accomplish this, I did not want to litter the code with method calls to the database to save data. To me, having method calls into separate objects that are my ‘data layer’ is not the true separation OOP and design patterns should be able to provide. By making method calls and instantiating objects inline, you are still coupling your business logic to the data layer.
I decided that I would forego the traditional inlined calls and use a more dynamic method of invoking database calls. Instead of calling database logic directly, I inserted events into critical points of the application that could bubble back up to a static “ServerApplication” object’s events. This way, the business logic and actual application was merely notifying any listeners of something occurring, whether or not that resulted in a database transaction was up to the listeners.
Who’s Listening
To further separate the listeners from the application, I chose to use the method of dynamically loading the listeners by means of an interface and the application configuration file. Following the ASP.NET example, I called these objects “IApplicationModule” and made an app.config section of “appModules”. These modules are read by the “ApplicationModuleManager” on application initialization and allow any modules to be instantiated and bind to events.
Once loaded, these modules are given the opportunity to bind to events in the “ServerApplication” object or throughout any other events that are either static, or can be accessed through statics. This give us the opportunity to configure our abstracted logic classes to be invoked when they are required.
Uses
This architectural model has several situations I expect it can be applied to, and probably more that I have not considered. The primary uses seem to be:
· A server-side application that deals mostly with saving data (little retrieval of data from a database). This type of application can benefit from this model because the database becomes optional, and the database code is never inlined.
· A server-side application that needs to respond to hardware or other similar events in real time to update UI’s, save logs, send notifications or execute other tasks. The modules can each become components that handle a certain notification or reaction that the system takes.
· A client-side Windows Forms application that requires an extensible plugin model capable of interrupting certain processes of the system.
Furthermore, this architecture gives several interesting opportunities for debugging. Using a small amount of reflection code, a module could attach to all of the events of a class and trace them out to a console. This would enable a realtime view of events in the system that can be extremely useful for runtime instrumentation.
Benefits
The core benefits of such a system appear to be the true separation of code. This system provides a method by which modules of the application can be fully contained, and where the business logic does not have to rely on the reactions that occur from the processing. In addition, upgrades to such a system become much simpler because many upgrades can be made by adding an assembly with a new module and never touching the rest of the deployment.
Summary
I wrote this mostly as a case study for myself, but decided to publish it for others to comment on or use. I know this is not very complete, and is a fairly rough document, but I encourage you to look at the code sample I included (it is a running template for this type of application). If you are looking to create a Windows Service application that includes the ability to have modules, this might be useful to you. The solution is already stubbed out with the objects discussed above and is already capable of loading modules. Furthermore, the solution is configured in such a way that you can run the application in a console without requiring the registering of the Windows Service. This alone is a big time saver.
Leave me your comments and tell me if this article was useful or if I should expand on it. Also, tell me if you know what “by-the-book” design pattern this is, I’d like to have the “official” name. I look forward to some new ideas.
*Update Josh Einstein gets the grand prize for naming the pattern, "Observer". I was trying to name the entire thing, including the plugin model -- but this was kind of stupid, because thats the implementation not the pattern.