Controller vs Model: dove inserisco l'elaborazione dell'input dell'utente?

Il tuo primo esempio è quello giusto.

if (action == "insert") Model.insert(data)

Ma dovresti provare a pensarlo in questo modo: Hai un'applicazione e qualsiasi interfaccia (UI, test, CLI, ecc.) È semplicemente questa: solo un'interfaccia.

Le interfacce con un'applicazione dicono cosa fare e recuperano i dati da esso. Questo è tutto ciò che fanno.

Quindi la tua interfaccia in questo esempio è il controller. Il fatto che il controllore prenda l'output dell'applicazione e lo renda all'interno di un modello HTML è presumibilmente "casuale".

In un'altra nota, so che hai detto che non utilizzerai alcun framework esistente, ma dovresti almeno tenere presente quanto segue:

1. Imparare a utilizzare un framework non è sempre semplice e agevole, ma ci vorrà meno tempo rispetto al tentativo di implementare il set di funzionalità da solo.
2. Potresti non essere ancora consapevole di tutte le insidie che stai per incontrare. Questi sono tutti coperti, in un modo o nell'altro, in grandi framework MVC.
3. Potresti non sapere (e probabilmente non lo sai) tutti i requisiti futuri o della tua applicazione. Ma i framework ti consentono già di sviluppare qualcosa di semplice oggi e di aggiungere facilmente nuove funzionalità domani (perché sono integrate e costruite in modo che possano essere facilmente integrate in qualsiasi momento).

Ho visto che i tuoi esempi "indipendenti dalla lingua" erano praticamente Python. Se ti piace la lingua, dovresti sapere che Django è uno dei framework MVC più grandi e documentati (in generale, non solo in Python ).

Dovresti farlo nel controller, sicuramente.

Il modello dovrebbe rappresentare solo lo stato attuale della tua applicazione. Qualsiasi controllo del comportamento delle applicazioni dovrebbe essere gestito dal controller, questo è il suo scopo.

Proverò a spiegare per definizioni: -

• Modelli contengono o rappresentano i dati con cui gli utenti lavorano. Questi possono essere modelli a vista semplice, che rappresentano solo i dati trasferiti tra le viste e controllori; oppure possono essere modelli di dominio, che contengono i dati in a dominio aziendale nonché le operazioni, le trasformazioni e le regole per manipolando tali dati.
• Le viste vengono utilizzate per eseguire il rendering di alcune parti del modello come interfaccia utente.
• I controllori elaborano le richieste in arrivo, eseguono operazioni sul modello, e seleziona le viste da rendere all'utente.

Quindi, dovresti farlo in Controller.

Il controller è solo l'intermediario tra la vista e il modello. L'esempio che hai fornito è un povero esempio di "input dell'utente". L'esempio è di operazioni CRUD necessarie per eseguire la logica richiesta dall'utente dalla vista.

In questo caso molto semplice, la vista deve eseguire un'azione di database, CRUD. Quindi, in questo semplice caso, il controllore passa semplicemente il dovere al Modello che gestisce le operazioni del DB.

L'input dell'utente entra in gioco quando chiedi "cosa sto creando?". L'utente fornisce informazioni che potrebbero essere necessarie per eseguire un BL e un processo di verifica dell'input dei dati. Questo è quando hai bisogno di altri livelli per assistere MVC.

Quando modifichi interattivamente qualcosa, mi piace pensare che ci siano due "modelli". C'è il "modello di entità" che è lo stato persistuto e c'è il "modello di modifica" che è lo stato corrente dei dati durante la modifica interattiva.

In genere non sono la stessa cosa. Ad esempio, ci sono stati consentiti nel modello di modifica che non sono consentiti nel modello di entità (come se non avessi compilato un campo obbligatorio).

Quindi il modello di modifica e il modello di entità (per quanto mi riguarda) dovrebbero essere entrambi parte del tuo livello aziendale, perché entrambi contengono regole di business. So che molte persone che utilizzano MVVM pensano che ViewModel debba essere il modello di modifica. Non penso che sia una regola dura e veloce, e nella mia attuale applicazione li sto tenendo separati.

Quindi, Pankaj ha detto:

Controllers process incoming requests, perform operations on the model, and select views to render to the user.

In base a ciò che ho detto sopra, ci sono due tipi di azioni:

1. Le normali azioni di modifica (cambiando una selezione in un menu a discesa che ha un effetto su un altro campo) interagiscono solo con il modello di modifica. Il controller crea quindi una nuova vista in base al nuovo stato del modello di modifica.
2. Le operazioni "CRUD" che eseguono il commit dei dati devono innanzitutto verificare la validità del modello di modifica (richiamando il modello di modifica stesso) e, se valido, devono quindi eseguire il commit delle modifiche al modello di entità delegando a una sorta di "mappa" metodo nei modelli. In genere ciò impegna le modifiche a un archivio dati condiviso come un database. Gli altri utenti possono quindi vedere le modifiche.

Quindi il controller gestisce tutte le richieste di input, ma delega il lavoro al modello. Dopo aver delegato il lavoro al modello, esegue nuovamente il mapping del modello sulla vista (in genere creando un'istanza di una nuova vista e passando il nuovo stato del modello di modifica).