J
J.Bijleveld
Hello,
I have a design issue I would like to discuss with anyone interested.
I am wondering what kind of design pattern would fit my situation,
perhaps not a standard (GoF) pattern but what I mean is just a
standardized way to solve this problem.
This is the issue:
I'm involved in the C# development of a framework for ASP.NET websites
(3-tiers). It uses Managers classes for business logic like license
management. Those managers are accessed from many locations and should
be always available, they all implement their own interface.
The framework should provide a standard implementation of each manager
but if the framework is used in a project, it must be possible to
replace the manager with another one to add specific features for that
project (like another licensing schema).
Possible solution:
Now, I create each manager in the Application_Start of the global.asax
file and store them in the Application object. They are then always
available for other classes.
Problems with it:
- If I want to use the default managers, I still have to create them
in a project where I use the framework. It would be nice if the
project shouldn't have any knowledge of which are the default
managers.
- The Application object is not type safe
- Each manager has only one instance since there's no other way for
components to determine which manager to instantiate.
I have the following ideas for a better solution:
- Create a static object SuperManager which has a property for each
manager of the type of the interface of that manager (-> typesafety
and one central location)
- use the web.config file to store the full classname and assemblyname
of the manager to be used. (-> dynamicly determine which manager to
use)
- instead of creating managers in the global.asax, the static methods
of the SuperManager can use web.config to find which manager to
instantiate for each property. It can call a static method on the
manager, which determines if it's a singleton or a new instance of the
manager must be created. (-> singleton issue)
I also thought about some kind of registration mechanism but I
couldn't figure out one that resolved all the issues I described.
I'm very interested to hear if anyone else also had this problem and
how you solved it, and also to hear what you think about my proposed
better solution.
Thanks in advance!
Regards,
Jeroen Bijleveld
I have a design issue I would like to discuss with anyone interested.
I am wondering what kind of design pattern would fit my situation,
perhaps not a standard (GoF) pattern but what I mean is just a
standardized way to solve this problem.
This is the issue:
I'm involved in the C# development of a framework for ASP.NET websites
(3-tiers). It uses Managers classes for business logic like license
management. Those managers are accessed from many locations and should
be always available, they all implement their own interface.
The framework should provide a standard implementation of each manager
but if the framework is used in a project, it must be possible to
replace the manager with another one to add specific features for that
project (like another licensing schema).
Possible solution:
Now, I create each manager in the Application_Start of the global.asax
file and store them in the Application object. They are then always
available for other classes.
Problems with it:
- If I want to use the default managers, I still have to create them
in a project where I use the framework. It would be nice if the
project shouldn't have any knowledge of which are the default
managers.
- The Application object is not type safe
- Each manager has only one instance since there's no other way for
components to determine which manager to instantiate.
I have the following ideas for a better solution:
- Create a static object SuperManager which has a property for each
manager of the type of the interface of that manager (-> typesafety
and one central location)
- use the web.config file to store the full classname and assemblyname
of the manager to be used. (-> dynamicly determine which manager to
use)
- instead of creating managers in the global.asax, the static methods
of the SuperManager can use web.config to find which manager to
instantiate for each property. It can call a static method on the
manager, which determines if it's a singleton or a new instance of the
manager must be created. (-> singleton issue)
I also thought about some kind of registration mechanism but I
couldn't figure out one that resolved all the issues I described.
I'm very interested to hear if anyone else also had this problem and
how you solved it, and also to hear what you think about my proposed
better solution.
Thanks in advance!
Regards,
Jeroen Bijleveld