Attualmente sto valutando alternative al refactoring di un drivermanagement.
Nella mia architettura multitier ho
BaseClass
-
DAL.Device
// la mia entità
Interfacce
-
BL.IDriver
// gestisce il processamento dei dati tra l'applicazione e il dispositivo -
BL.IDriverCreator
// crea unIDriver
da unDevice
-
BL.IDriverFactory
// gestisce le richieste di creazione del driver
Ogni specializzazione di Device
ha un'implementazione IDriver
corrispondente e un'implementazione IDriverCreator
corrispondente.
Al momento la mappatura viene risolta tramite un controllo del tipo all'interno del livello aziendale / DriverFactory
. Ciò significa che ogni nuovo driver ha bisogno di un codice di modifica all'interno di DriverFactory
eb) che fa riferimento alla nuova implementazione / assembly IDriver
. Dal punto di vista dei clienti ciò significa che ogni nuovo driver, utilizzato o meno, necessita di una riconvalida complessa del proprio ambiente hardware, perché è un processo critico.
La mia prima ispirazione è stata l'utilizzo di un micro-caliburn come nameconvention
vedi Caliburn.Micro: Xaml Made Easy
-
BL.RestDriver
-
BL.RestDriverCreator
-
DAL.RestDevice
Dopo aver ricevuto RestDevice
in IDriverFactory
posso caricare tutte le DLL driver tramite reflection e fare un namesplitting / confronto (estraendo xx da xxDriverCreator e xxDevice)
Un'altra idea sarebbe un attributo personalizzato (che porta anche a confrontare le stringhe).
La mia domanda: è un buon approccio sopra i bordi dei livelli? In caso contrario, quale sarebbe un buon approccio?