Well the first thing you should look into is the notion of Add-Ons in
general (maybe do a web search for it). This will help you understand what
AddOn's are and different ways of implementing them.
Next, take a look at Interfaces because that is a core part of Add-On
implmentations. You will need a common set of methods (aka an Interface)
that can be used to access the Add-On.
Here is an example of an Interface and a way that you could use it in your
application.
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++
interface IAddOn
{
String Name(); //Returns a human readable name of this AddOn like
"Printing"
String Description(); //Returns a brief description like "Allows
Printing of internal documents"
bool Startup(); //Performs any init/startup code that is needed and
returns true/false as a success result.
bool Shutdown(); //Performs any shutdown code that is needed and returns
true/false as a result.
void Show(); //Informs the AddOn that it should display itself.
void Hide(); //Informs the AddOn that it should hide itself.
void Execute(String cmd); //Tells the AddOn to execute the given
command. cmd could be an xml string or anything?
}
Now if you are going to have a standard application that these AddOns will
be part of then maybe you could use a menu system to show the available
"options" that are intalled. The menu system could be an actual menu or
maybe just different buttons on a form that are clicked on.
The application could look at the files in a specific directory (maybe
\AddOns) and use Reflection to load and create an instance of each of the
files contained in it. Each file (assembly) would have a class that is
derived from the IAddOn interface so you could determine what class you
should instantiate. Or maybe you have a config file that contains a list of
assembly files and class names that should be loaded.
After loading each of the AddOns the application could call Startup() on
each one so that they could do any initializing they needed.
Using the Name() member of the IAddOn interface you could dynamically add a
menu item that the operator could select in order to activate the AddOn.
When the operator selected an AddOn from the menu you could call the Show()
method or maybe the Execute() method to have the AddOn peform it's task.
When the application is closed down you would want to call Shutdown() so
that the AddOn's could do any uninit type of stuff they needed like closing
files, etc.
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++
The nice thing about this type of setup is that you could have different
types of AddOn's. Maybe you have an interface used for user selectable
options, and another interface for background utilities.
Or, maybe you want to implement some sort of secutity mechanism. The
Interface could have a method that takes a username and returns true if it
is allowed to use the AddOn. This way you could have one application with
all the AddOns available but the user logs and only sees what they are
allowed to use.
Kind of a brief overview of this type of development but maybe it can give
you some insite?
"Steve" <ss*@sss.com> wrote in message
news:ev***************@TK2MSFTNGP09.phx.gbl...
Hi,
I am sitting down to design our next set of internal apps. I would like
to approach this in a way that would allow me to break logical parts of
the application that handle specific tasks into modules. For example,
assuming we have 4 main tasks to accomplish:
- Printing
- Editing
- Viewing
- Inventory Management
Each of those tasks would have an associated UI(User Control) with all
relevant UI controls, for example printing would have printing options,
printer names, etc.
My motivation for wanting to make these separate is that different
combinations of these modules need to be rolled together into
applications. For example, at my desk, I would want an application that
would support all 4 tasks, while in the shop, they only need Printing,
Inventory and Viewing. Someone else might only need Viewing.
Rather than develop all modules under the same project and build separate
binaries with various modules enabled or disabled, I would rather have a
project for each module, then a project for each combination of modules
and include the modules that I need.
I suppose this is actually a sort of plug-in architecture that I'm looking
for. I haven't ever done anything like this and am interested in how most
of you would approach this? Anyone know of any good articles or books on
the subject?
Thanks for reading,
Steve