Sto avendo difficoltà a determinare dove dovrebbe trovarsi la mia logica IO all'interno della mia applicazione. In questa applicazione ci sono più IO Device sia USB che seriali. Al momento ho l'idea di separare la comunicazione con i dispositivi dalle loro forme di controllo e thread di controllo; vale a dire fare clic su un pulsante su un modulo e il dispositivo fa qualcosa o alcune serie di azioni porta a un thread non-UI che comanda il dispositivo.
Ho iniziato a lavorare con i dispositivi seriali. Quindi ho prima scritto una classe RS232Comm che avvolge la classe System.IO.Ports.SerialPort in qualcosa di bello e sicuro ( lock sulle routine Read e Write ) in modo che più thread possano accedere al dispositivo simultaneamente.
Da qui ho in programma di sottoclasse da RS232Comm per ogni dispositivo seriale, tutte le sottoclassi saranno oggetti singleton che costringono tutte le comunicazioni a passare attraverso il singleton.
Il mio attuale problema è dove dovrebbe essere la logica su come agisce il dispositivo e il suo stato? Fondamentalmente, se voglio interrogare un dispositivo per il suo stato attuale, lo stato dovrebbe essere contenuto in qualche oggetto ed essere passato in giro ad ogni classe di controllo (possibilmente un evento NewStateObject )? Quando una classe di controllo vuole inviare un comando al dispositivo, dovrebbe controllare l'input prima di chiamare il singleton, o il singleton dovrebbe controllare l'input prima di scrivere sulla porta seriale?
Mi sembra che abbia più senso che il singleton verifichi l'input e l'output per gli errori insieme al mantenimento dell'oggetto oggetto dei dispositivi. In questo modo il codice non è duplicato nelle classi di controllo. Ma sento che questo farà davvero ingrassare le classi Singleton a centinaia di linee.
Al di fuori dello scopo del mio progetto, se dovessi avere solo una corrispondenza 1 o 1 o una classe IO per controllare la forma / logica, avrebbe più senso fonderli in una classe che "fa tutto" per quello dispositivo?