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 unIDriverda 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?