Design corretto MVC e classi di supporto

2

Ho letto in Model-View-Controller e mi stavo chiedendo dove una cosa come una classe XyzClient si adatterebbe a questo progetto. Divisione di MVC è facile quando tutto ciò che hai sono alcune viste da visualizzare, un codice per gestire le interazioni dell'utente e alcune entità di database (magari persiste).

Ma dove si inserisce qualcosa come PaypalClient o DateFormatter ? Quando parlo di modello, penso a qualche entità di database come Student o Course ma non di qualche helper come PaypalClient . È un modello o un controller? E dove va bene qualcosa come DateFormatter (un helper per le date di formattazione)? O dovrei impedire tali classi durante la progettazione di MVC (senza di loro otterrei un enorme codice del controller)?

    
posta miho 26.11.2014 - 09:47
fonte

1 risposta

3

Nelle applicazioni più grandi, trarrai vantaggio da un'ulteriore modularizzazione oltre MVC. Il modello può essere suddiviso in:

  • Oggetti di dominio - come studenti o corsi che hai menzionato
  • Data access objects (DAO) - codice per caricare / salvare oggetti dominio
  • Livello di servizio: logica aziendale che opera su oggetti dominio

Spesso le persone dimenticano il livello DAO perché se si sta utilizzando un ORM, lo fa internamente. Tuttavia, il tuo PaypalClient è un esempio di un DAO esplicito. Se vuoi fare un buon lavoro, assicurati di separare gli oggetti del dominio Paypal dagli oggetti di accesso ai dati.

DateFormatter dovrebbe essere parte della vista. Stai usando i modelli per la vista? La maggior parte dei sistemi di template ti consente di definire filtri personalizzati, che convertono un oggetto in una stringa. Esiste anche il modello MVVM , ma ciò è più importante quando si esegue un'elaborazione complessa per la vista; per la formattazione semplice della data che è eccessivo.

    
risposta data 26.11.2014 - 11:23
fonte

Leggi altre domande sui tag