Struttura classi lato client nel progetto UML

5

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?

    
posta liggiorgio 20.11.2015 - 01:02
fonte

1 risposta

3

Question is: is having a control class in my client application useful, redundant, or wrong at all? How can I improve my classes structure?

È utile. Il controller, ctrClientManager, incapsula la messaggistica sul socket; è responsabile della creazione del socket, dei flussi di messaggi e di altri impianti idraulici relativi ai messaggi. Ogni classe di limite ha bisogno di questa funzionalità e porterà a duplicazione del codice se ogni classe di limiti invierà direttamente messaggi.
Migliora la manutenibilità , perché se qualcosa deve essere cambiato genericamente nella comunicazione tra client e server, è possibile farlo in un punto centrale (il controller) invece di adattare ogni singola classe di confine .
Migliora l'affidabilità , perché la probabilità che ci sia un bug in un pezzo centrale di codice è inferiore alla possibilità che ci sia un bug in una delle tante copie dello stesso codice.

A proposito, si consiglia di applicare il pattern MVC, in cui ogni vista (boundary class) ha il proprio controller, per controllare l'interazione dell'utente. Inoltre, dovresti avere il controller di messaggistica centrale, chiamato ctrClientManager nel tuo esempio.

    
risposta data 21.11.2015 - 20:02
fonte

Leggi altre domande sui tag