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?