A groovy little pluggable framework
Oh, this is just SO satisfying. I have finished refactoring my app and it's so cool to see this working just the way I had dreamt it up. I was only able to do this from a lot of ideas I have collected from many of the presentations at Vermont.NET over the last six months - most notably for this particular solution: Ken Getz on Visual Inheritance in Windows Forms (April 2003), Carl Franklin on Objects (August 2003) (this really got me thinking about taking my use of inheritence to a whole new level) and Billy Hollis on Dynamically Loading Forms and other Advanced Object Techniques (October 2003). Hey whad'ya know - all three are INETA speakers, too!
I also had some prior education with reflection with a previous app that dynamically loaded ActiveX User Controls into a .net windows form application.
I am going to attempt to explain the basic setup here in case anyone might be able to learn from it. If you look at this in a browser (not your aggregator) you will see that I have color coded some of the objects to make it a little easier to explain.
I am creating a pluggable framework of test entry forms. These are a variety of different tests that are performed on building sites - making sure a factory doesn't sink into the ground or a road doesn't buckle or a bridge doesn't collapse.
Every test will have a few things in common - not just data entry, but functionality as well. So I have built those things into a base form and an associated base class. The base form lives is in its own DLL. The base class is in my Business Layer.
Then for each new test, I create a new form inherited from the base form and add to it additional controls that are specific to that test. I also create a new class that inherits from the base class. This new class also has it's own explicit functionality.
This is the whole point behind inheriting classes. So why did I find it so challenging? Combining the derived forms AND derived classes was a little daunting and took some experimentation before I understood how everything worked together. It felt to me something like that now famous “cog“ ad that Honda did.
When the user chooses to work with TestA, an instance of “FormTestA” is created. It gets what it needs from the base form. The base form creates the base class, then FormTestA creates IT's derived class and get's what it needs from the base class that the base form created. (Are you with me so far?) It is really fun to step through the code and watch the debugger go back and forth between the two classes and the two forms. Some of that coolness I think I may have had something to do with -- but most of it feels like magic.
Then the last trick was to make this really pluggable because we plan to add tests over time and all I want to do is throw another dll into the mix. This is where reflection comes in. Each test will has it's own dll containing a derived form and a derived class. That dll references the business layer and the BaseForm.dll. In the ParentMDI form, when the user selects which test to work with, I instantiate the specific test's derived form via reflection and then it does all of it's own work from there. THere is heavy interaction from the parentMDI form which calls functions that reside in the derived forms and classes. And it all just works!
It is just so much fun to finally have the tools (i.e comprehension) to create a solution that uses some of the techniques that used to make me dizzy. So Ken, Billy, Carl and a HOST of others - THANKS!! Oh, and always -- Deborah Kurata who dragged me into the world of Objects many years ago and continues to enlighten many on OOP. Thanks Deborah!!