D
d0wsdkn02
I need some architecture help. Our app is similar between clients, but
every client has specific needs that can require us to change anything.
I'll concentrate on one class below, but potentially any number of
methods, fields, additional classes, or anything could need to be
changed for a client.
With two clients, one way to implement this would be:
default/Biz.dll
public class CustomerBase // with default implementation
client1/Biz.dll
public class Customer : CustomerBase // with modifications
client2/Biz.dll
public class Customer : CustomerBase // with modifications
The two client dll's would reference the default dll and we would
instantiate the client's version via a factory.
Various issues come up with this implementation:
1. The client dll's have to include Customer implentations (even if
empty). Lots of repetition between clients. Also, if I add a new
class in CustomerBase I have to modify every client dll.
2. What happens when two clients share the same, but different from the
Base, logic. Here it would be a copy and paste and will exist in two
places. Not good.
There's other issues and I would imagine maintainability would spiral
out of control as new clients are added.
A possible improvement I've thought about (kind of a dynamic class
loading factory):
Have Customer defined in all dll's (no CustomerBase). Configure a
hierarchy of dll's for each client (i.e. look in client1 first, then
look in default). Dynamically make the class at run-time based on the
config. Problem 1 above is solved since if no implementation is there
it will just move to the next dll on the list. Problem 2 could be
solved by adding more levels to the hierarchy. Of course,
implementation and going against OOP could be problematic.
To implement it I was thinking:
- Make the class using reflection and the Builder classes (TypeBuilder,
etc.) based on the contents of the dll's in the config.
- Wrap a dynamic proxy (something like
http://www.castleproject.org/index.php/DynamicProxy) around the methods
in the default implementation and override it's implementation
according to the config when called.
- Similar to above, but use full AOP to implement (AspectSharp, etc.).
- Some kind of partical classes implementation over multiple dll's (not
sure if it's possible, and we might have to use .NET v1.1 anyway).
Anybody have thoughts on how best to design this? In short, we want to
flexibly override, add, and refactor anything from the default
implementation; and be able to deploy any dll independently.
Are there any good sample apps that shine in this regard?
Thanks for any help,
feech
every client has specific needs that can require us to change anything.
I'll concentrate on one class below, but potentially any number of
methods, fields, additional classes, or anything could need to be
changed for a client.
With two clients, one way to implement this would be:
default/Biz.dll
public class CustomerBase // with default implementation
client1/Biz.dll
public class Customer : CustomerBase // with modifications
client2/Biz.dll
public class Customer : CustomerBase // with modifications
The two client dll's would reference the default dll and we would
instantiate the client's version via a factory.
Various issues come up with this implementation:
1. The client dll's have to include Customer implentations (even if
empty). Lots of repetition between clients. Also, if I add a new
class in CustomerBase I have to modify every client dll.
2. What happens when two clients share the same, but different from the
Base, logic. Here it would be a copy and paste and will exist in two
places. Not good.
There's other issues and I would imagine maintainability would spiral
out of control as new clients are added.
A possible improvement I've thought about (kind of a dynamic class
loading factory):
Have Customer defined in all dll's (no CustomerBase). Configure a
hierarchy of dll's for each client (i.e. look in client1 first, then
look in default). Dynamically make the class at run-time based on the
config. Problem 1 above is solved since if no implementation is there
it will just move to the next dll on the list. Problem 2 could be
solved by adding more levels to the hierarchy. Of course,
implementation and going against OOP could be problematic.
To implement it I was thinking:
- Make the class using reflection and the Builder classes (TypeBuilder,
etc.) based on the contents of the dll's in the config.
- Wrap a dynamic proxy (something like
http://www.castleproject.org/index.php/DynamicProxy) around the methods
in the default implementation and override it's implementation
according to the config when called.
- Similar to above, but use full AOP to implement (AspectSharp, etc.).
- Some kind of partical classes implementation over multiple dll's (not
sure if it's possible, and we might have to use .NET v1.1 anyway).
Anybody have thoughts on how best to design this? In short, we want to
flexibly override, add, and refactor anything from the default
implementation; and be able to deploy any dll independently.
Are there any good sample apps that shine in this regard?
Thanks for any help,
feech