I´m having some trouble deciding in which way to go…
I’ve got this application which consists of one base project, and one project for the application, the application project contains code targeting a specific system, system application.
The base project is an abstract class containing abstract methods which each system specific application project implements.
The thing is that the system application projects may/will have customer specific adjustments and i don’t want to put this code in the system application assembly.
I´m not sure where to start or how to accomplish this in a way that is secured for the future, easy to maintain and were i can add more customer specific code without rewriting the system application assembly.
The idea is to have one base project (dll), one system application project for each system (dll) and then put customer specific adjustments in one customer unique project (dll).
Rob.Core.dll
Rob.Application.BigSystem.dll
Rob.Application.BigSystem.Customer.BigCompany.dll
Rob.Core.dll is the base abstract project.
Rob.Application.BigSystem.dll is an system specific project (BigSystem) and derives from Rob.Core.dll.
Rob.Application.BigSystem.dll should check if the current customer, BigCompany, has any unique adjustments and if so load the Rob.Application.BigSystem.Customer.BigCompany.dll assembly which may contain overrides of methods or extensions of objects, extra fields etc.
Well, time to summarize…
Im not sure which way to go here, i could create one base project (abstract) and from each system specific project derive from this, seems as this is the way to start.
Then create a new project for each customer that has a set of unique adjustments and just override all methods in the system specific project.
The problem is then, which project is the one that executes on runtime? The system specific project or the customer unique project?
If the system specific project executes how should it load all the customer adjustments (if there are any, not every customer got unique adjustments)?
This is quite a big question but i’m hoping in some tips which will help me write the architecture.
Best regards
Robert
My two suggestions, from what you said:
I would focus on types, not projects. “Projects” are just a way to create an assembly full of usable types – they don’t, in and of themselves, inherit anything, nor do they allow for subclassing, etc. The questions I would be asking: What types would need to be customized for a customer? How would this customization take place?
Once you have those figured out – I would suggest looking into depedency injection or extensibility frameworks. A good DI framework to try would be Ninject. A good extensibility framework is MEF.
If the types will always need to be supplied in a customer-specific manner, then you probably want to focus on DI. If the types are something that will be an optional extension to the default behavior, then just doing some form of plugin system/extensibility system like MEF may be simpler.