Disaccoppiamento dei componenti software tramite convenzione di denominazione

2

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 un IDriver da un Device
  • 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?

    
posta csteinmueller 20.08.2014 - 16:11
fonte

3 risposte

1

Non vedo come si possa aggirare la dipendenza da un'interfaccia comune per i plugin (IDriver in questo esempio). Forse non lo capisco bene. In ogni caso, la convenzione di denominazione è il modo preferito e moderno per strutturare il software sulla convenzione. Asp.net stesso usa il modello.

Potresti voler includere uno strumento per convalidare gli assembly per assicurarti che siano conformi alla convenzione, ma altrimenti dico di andare a farlo.

    
risposta data 26.08.2014 - 21:03
fonte
1

Affidarsi alla convenzione di denominazione per la creazione di un meccanismo di estensione è un approccio ben noto per evitare codice di piastra caldaia non necessario e seguire il principio di apertura / chiusura. Tuttavia, la convenzione dovrebbe essere ben documentata e dovresti prendere alcune precauzioni contro gli errori di battitura, ad esempio se qualcuno scrive "Dispositivi" o "Devce", assicurati che il tuo gestore di driver ne venga a conoscenza e segnala un errore.

    
risposta data 20.08.2014 - 20:41
fonte
0

Vorrei scegliere un attributo personalizzato su una convenzione di denominazione. Questo è il metodo utilizzato nella maggior parte delle API basate su reflection in .net. Previene gli errori causati da corrispondenze accidentali o mancate corrispondenze.

    
risposta data 26.08.2014 - 19:20
fonte

Leggi altre domande sui tag