Decoupling software components via naming convention
- by csteinmueller
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 device
BL.IDriverCreator //creates an IDriver from a Device
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 RestDevicewithin 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?
