Io e due miei colleghi universitari stiamo progettando un semplice software CMS per un esame universitario utilizzando UML. Tale software ha solo bisogno di trattare con l'invio di un articolo, l'assegnazione di un articolo per la revisione, l'invio di una revisione e la valutazione di un articolo. La nostra soluzione prevede un'architettura client-server a 3 livelli, con piccoli client che richiedono servizi e un server che risponde alle richieste tramite l'interfacciamento con un DBMS (dati persistenti) e un server SMTP (notifiche e-mail).
Sono a un punto in cui non posso decidere come strutturare le mie classi lato client. Ho individuato un insieme di classi boundary che rappresentano singoli servizi e contengono metodi correlati (autenticazione, invio di documenti, documenti di revisione ...) e una singola classe control che i ruoli sono richiedere la connessione al server e la creazione di una nuova sessione e contiene i metodi per inviare effettivamente messaggi al server.
Questo è secondo il principio di responsabilità singola che afferma che ogni classe dovrebbe essere responsabile di una singola funzionalità del software: quindi, Ho una classe per iscrivermi / loggarmi, una per inviare un articolo, e così via, e poi la classe control che riceve richieste da altre classi boundary e invia messaggi al server.
D'altro canto, mi è stato detto da altre persone che ho chiesto che potessi anche sbarazzarmi della mia classe controller sul lato client e dare direttamente ai metodi delle classi boundary inviare messaggi di richiesta al server. Mi sembra ancora legittimo: le classi boundary inviano solo richieste in base al particolare servizio che avrebbero dovuto fornire all'utente.
La domanda è: avere una classe control nella mia applicazione client utile, ridondante o errata? Come posso migliorare la struttura delle mie classi?