I’m currently evaluating alternatives to refactor a drivermanagement.
In my multitier architecture I have
Baseclass
DAL.Device
//my entity
Interfaces
BL.IDriver
//handles the dataprocessing between application and deviceBL.IDriverCreator
//creates anIDriver
from aDevice
BL.IDriverFactory
//handles the driver creation requests
Every specialization of Device
has a corresponding IDriver
implementation and a corresponding IDriverCreator
implementation.
At the moment the mapping is fix via a type check within the business layer / DriverFactory
. That means every new driver needs a) changing code within the DriverFactory
and b) referencing the new IDriver
implementation / assembly. On a customers point of view that means, every new driver, used or not, needs a complex revalidation of their hardware environment, because it’s a critical process.
My first inspiration was to use a caliburn micro like nameconvention
see Caliburn.Micro: Xaml Made Easy
BL.RestDriver
-
BL.RestDriverCreator
-
DAL.RestDevice
After receiving the RestDevice
within the IDriverFactory
I can load all driver dlls via reflection and do a namesplitting/comparing (extracting the xx from xxDriverCreator and xxDevice)
Another idea would be a custom attribute (which also leads to comparing strings).
My question: is that a good approach above layer borders? If not, what would be a good approach?
7
I don’t see how you can get around the dependency on a common interface for plugins (IDriver in this example). Maybe I am not understanding that right. Anyway, naming convention is the preferred and modern way of structuring software over convention. Asp.net itself uses the pattern.
You may want to include a tool to validate the assemblies to make sure they comply with the convention, but otherwise I say go for it.
Relying on naming convention for creating plugin mechanism is a well known approach to avoid unnecessary boiler plate code and to follow the Open/Closed principle. However, the convention should be documented well, and you should take some precautions against typos – for example, if someone writes “Devices” or “Devce”, make sure your driver manager will become aware of that and signal an error.
1
I would choose a custom attribute over a naming convention. This is the method used in most reflection based API’s in .net. It prevents mistakes caused by accidental name matches or mismatches.