By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,773 Members | 1,838 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,773 IT Pros & Developers. It's quick & easy.

advice needed for modularized development

P: n/a
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
Jan 24 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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

Jan 24 '06 #2

P: n/a
Very nice, that is a great overview!
I too had thought of the single "host" application that would host the add
ons and make them availablew based on the current users role.

I printed your message, it's a nice overview, I'll read it a couple times,
thanks for the post.

Have a good one,
Steve
"C.C. (aka Me)" <me@home.com> wrote in message
news:ts******************************@comcast.com. ..
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


Jan 24 '06 #3

P: n/a
One place to look at for a "big" example of this type of thing is the
Eclipse project.

http://www.eclipse.org/

It is an "everything but nothing at all" type of framework. It provides the
"general application" and you provide the "components that do something". I
have not used it but have dealt with others that have and it seems to work
for them.

Might be to big of a thing for your project but at least it can give you
some ideas maybe?
"Steve" <ss*@sss.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
Very nice, that is a great overview!
I too had thought of the single "host" application that would host the add
ons and make them availablew based on the current users role.

I printed your message, it's a nice overview, I'll read it a couple times,
thanks for the post.

Have a good one,
Steve
"C.C. (aka Me)" <me@home.com> wrote in message
news:ts******************************@comcast.com. ..
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



Jan 24 '06 #4

P: n/a
Yeah, Eclipse is overkill for what I want.

I wonder how I can debug my Add-Ons outside of the host? To launch them in
the debugger, they would need to be WinForms application, but I can't
imagine it would be proper for a "Host" winforms app to host another
winforms app. Does that make sense?

I google for AddOn led me to this article:
http://msdn.microsoft.com/msdnmag/is...10/plug%2Dins/

I haven't read it yet, just browsed but it sounds like a good place to start
for me.
"C.C. (aka Me)" <me@home.com> wrote in messag e
news:cd******************************@comcast.com. ..
One place to look at for a "big" example of this type of thing is the
Eclipse project.

http://www.eclipse.org/

It is an "everything but nothing at all" type of framework. It provides
the "general application" and you provide the "components that do
something". I have not used it but have dealt with others that have and it
seems to work for them.

Might be to big of a thing for your project but at least it can give you
some ideas maybe?
"Steve" <ss*@sss.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
Very nice, that is a great overview!
I too had thought of the single "host" application that would host the
add ons and make them availablew based on the current users role.

I printed your message, it's a nice overview, I'll read it a couple
times, thanks for the post.

Have a good one,
Steve
"C.C. (aka Me)" <me@home.com> wrote in message
news:ts******************************@comcast.com. ..
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



Jan 24 '06 #5

P: n/a
You should still be able to debug them.

Say you have the following projects:

MainApp (WinForm application project)
Comp1 (Class Library)
Comp2 (Class Library)

Now you can debug the Control Libraries if you add them to your MainApp
project. You can dynamically load them still from a config file or whatever,
but VS should see that you have the source code and allow you to debug them.

So you could debug them from within the normal application that your users
interact with.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Steve" <ss*@sss.com> wrote in message
news:ep**************@TK2MSFTNGP10.phx.gbl...
Yeah, Eclipse is overkill for what I want.

I wonder how I can debug my Add-Ons outside of the host? To launch them
in the debugger, they would need to be WinForms application, but I can't
imagine it would be proper for a "Host" winforms app to host another
winforms app. Does that make sense?

I google for AddOn led me to this article:
http://msdn.microsoft.com/msdnmag/is...10/plug%2Dins/

I haven't read it yet, just browsed but it sounds like a good place to
start for me.
"C.C. (aka Me)" <me@home.com> wrote in messag e
news:cd******************************@comcast.com. ..
One place to look at for a "big" example of this type of thing is the
Eclipse project.

http://www.eclipse.org/

It is an "everything but nothing at all" type of framework. It provides
the "general application" and you provide the "components that do
something". I have not used it but have dealt with others that have and
it seems to work for them.

Might be to big of a thing for your project but at least it can give you
some ideas maybe?
"Steve" <ss*@sss.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
Very nice, that is a great overview!
I too had thought of the single "host" application that would host the
add ons and make them availablew based on the current users role.

I printed your message, it's a nice overview, I'll read it a couple
times, thanks for the post.

Have a good one,
Steve
"C.C. (aka Me)" <me@home.com> wrote in message
news:ts******************************@comcast.com. ..
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
>



Jan 24 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.