E 'pericoloso per me dare alcune delle mie classi Model come metodi di controllo?

Question

E 'pericoloso per me dare alcune delle mie classi Model come metodi di controllo?

#1 da (5 voti)
#2 da (2 voti)

4

Nel mio progetto personale ho cercato di aderire a MVC, ma mi sono anche reso conto che attaccare troppo a MVC può essere una cosa negativa in quanto rende difficile la scrittura e costringe il flusso del programma in modi strani ( cioè alcune semplici funzioni possono essere eseguite da qualcosa che normalmente non lo farebbe ed evitare i costi generali associati a MVC.

Quindi comincio a sentirmi giustificato in questo compromesso:

Ho alcuni "programmi manager" che "possiedono" dati e hanno un modo per manipolarli, quindi penso che contino come entrambi parte del modello, e parte del controllo e per me è più naturale che tenerti separato. Ad esempio: Uno dei miei manager è PlayerCharacterManager che ha questi metodi:

void buySkill(PlayerCharacter playerCharacter, Skill skill);
void changeName();
void changeRole();
void restatCharacter();
void addCharacterToGame();
void createNewCharacter();
PlayerCharacter getPlayerCharacter();
List<PlayerCharacter> getPlayersCharacter(Player player);
List<PlayerCharacter> getAllCharacters();

_{Spero che i nomi delle mothod siano abbastanza trasparenti da non aver bisogno di spiegazioni.}

L'ho chiamato gestore perché aiuta a gestire tutti gli oggetti del modello "PlayerCharacter" che il codice crea e crea e mantiene una mappa di questi. Potrei anche averlo per memorizzare altre informazioni in futuro.

Ho in programma di avere altre due classi simili per questo tipo di controllo, ma orchestrerò quando e come ciò accadrà e cosa fare con i dati restituiti tramite una pura classe di controller. Questo dividere il controllo tra i responsabili informati e il controller, al contrario di operare solo attraverso un controller, sembra che semplificherà il mio codice e lo farà fluire di più.

La mia domanda è, è una scelta pericolosa, in termini di rendere il codice più difficile da seguire / testare / correggere? Questo qualcosa è stabilito come buono o cattivo o neutro? Non riesco a trovare nulla di simile, tranne l'idea di attori ma non è proprio il motivo per cui sto cercando di farlo.

Modifica: forse è necessario un esempio; Sto usando il controller per aggiornare la vista e accedere ai dati, quindi quando faccio clic sul pulsante "Aggiungi nuovo personaggio a un giocatore" chiameremo i metodi nel controller che poi andranno a dire alla classe PlayerCharacterManager di creare un nuovo personaggio Ad esempio, chiamerà la classe PlayerManager per aggiungere quel nuovo personaggio alla mappa giocatore-personaggio, quindi aggiungerà queste informazioni al database e dirà alla vista di aggiornare qualsiasi GUI effettuata. Questo è il tipo di "sequenza di controllo" che spero di creare con queste classi di manager.

architecture control-structures design-patterns

posta Pureferret 17.09.2012 - 14:24

fonte

2 risposte

5

In generale è pericoloso mescolare cose che si sono dimostrate buone da dividere, come nel caso del controllo delle applicazioni e del modello di dominio.

Ma non è il caso del tuo esempio. La tua lezione di "giocatore manager" (chiamerei Squadra o Gioco, ma non conosco gli altri), è una parte perfetta del Modello.

Come già accennato, probabilmente hai anche una vista 'basata su database'. Cerca di dimenticare il ruolo centrale dei dati (base): è solo il motore di persistenza, nient'altro. Non è il centro, è un servizio.

Il modello contiene tutta la logica della tua applicazione (logica, non dati, che in realtà deve contenere (cioè manipolare e restituire) alcuni dati, è solo il derivato dal fatto che contiene la logica). Una cosa su cui il Modello può dipendere è un servizio di persistenza, ad es. banca dati.

Quindi Model è principalmente API, non dati. Quindi il tuo esempio si inserisce perfettamente nel Modello.

La vista è, si spera, chiara: questa è quella che presenta parti del Modello all'utente.

Il controller (o altre cose nella classe di modelli MV *, come Presenter in MVP o View Model in MVVM) sono i più difficili da individuare. Il controller classico in MVC è quello che reagisce agli eventi (utente) e manipola il modello (di conseguenza, la visualizzazione aggiorna).

Quindi il tuo esempio non è sicuramente il Controller.

risposta data 17.09.2012 - 15:33

fonte

Leggi altre domande sui tag architecture control-structures design-patterns

Quali sono i punti chiave da valutare per selezionare un buon gateway SMS? Quali argomenti di Matematica discreta dovrebbe sapere lo studente di informatica medio?

score 2 · Accepted Answer

La differenza tra Modello e Controller può essere sottile, ma si riduce a questo: Chi è responsabile qui?

Se crei una classe che gestisce tutti gli aspetti di un PlayerCharacter, non è necessariamente un Controller. Qualcuno chiama questo manager, ad esempio una classe chiamata Engine che chiama tutte le rispettive classi per disegnare, eseguire calcoli, richiedere modifiche ai giocatori (si presume che PlayerCharacter venga chiamato qui). Il motore è il controller, non il PlayerCharacter.

Molto spesso, i parametri per controllare le classi sono configurazioni, che alterano gli attributi generici ma non dicono nulla sul modo in cui tale metodo deve comportarsi. In alternativa, le classi modello svolgono compiti molto specifici e dovrebbero essere trasparenti su ciò che fa. I loro parametri sono importanti perché influenzano direttamente il comportamento del metodo (per esempio getPlayersCharacter). Poiché tutti i metodi sopra elencati sono piuttosto trasparenti, puoi concludere che stai scrivendo una classe modello, non un controller.

I metodi per una classe controller sembrerebbero più simili a:

void Engine::run(Configuration c);
void Engine::run(Configuration c, Logger l);

Si noti che poiché fa una varietà di cose, è di natura molto generica. Idealmente, si tratta di un metodo relativamente breve che si basa su molte classi di modelli di livello superiore per eseguire le sue operazioni, ma a volte è necessario disporre di più di una classe Controller per gestire vari aspetti. Tuttavia il principio è lo stesso. In quelle classi vedresti poca differenza nella denominazione dei metodi. Basta essere cauti per includere metodi di controller generici in una classe modello diversa. Questa è l'essenza di MVC.

Spero che risponda alla tua domanda.