Dove collocare un certo tipo di funzioni nella struttura MVC

if I have some functions that help me deal with models, but isn't a model itself, where should I put it?

Se si tratta di classi di supporto per il modello, dovrebbero sedere con il modello. Si noti inoltre che il modello non è solo i modelli di database, è in realtà il modello di dominio. La tua logica di business e le regole di business risiedono lì, non solo le entità aziendali.

I created a function called "Add", and it receives the two arguments: "model name" and "properties" for that model, and the function uses the requested model and does all the work needed to add it to the database.

Questo suona come il tuo livello di persistenza. La persistenza dovrebbe far parte del Modello, almeno è così che l'ho usato e penso che dovrebbe esserlo, sebbene ci siano molte varianti di MVC.

Nel decidere dove dovrebbero vivere alcuni codici, classi, funzioni, ecc. (M, V o C) è una buona idea tenere presente il motivo base che esiste MVC e che è quello di separare le preoccupazioni. Con una buona implementazione MVC dovrebbe essere relativamente facile sostituire la C o la V con un'implementazione diversa. Quindi, quando lo fai, dovresti fornire un'altra implementazione per "Aggiungi" o dovrebbe essere già disponibile all'interno della M? ^(*)

EDIT: per rispondere alle nuove domande che hai chiesto

Where is the right place for validating user input? should it go to the model?

La convalida va sia nel modello che nel controller. Ma ci sono due tipi di convalida.

L'input dell'utente è convalidato all'interno del controller. L'utente ha compilato tutti i campi obbligatori? Abbiamo ricevuto tutto ciò che è necessario per fare una chiamata al modello? Questo tipo di cose. Il controller quindi massaggia l'input in parametri per il modello. Ad esempio, di solito invii cose come stringhe, ma il modello potrebbe aspettarsi un intero. Il controller adatta i dati di input e si assicura che sia valido per una chiamata Model.

Ora il modello esegue la propria convalida. Verifica dei parametri ricevuti e verifica delle regole aziendali. Non si preoccupa dell'input dell'utente, si preoccupa dei parametri ricevuti sulla chiamata. Come ho detto sopra, l'idea è di pensare a sostituire le parti di MVC. Se si sostituisce il controller e la nuova implementazione è bacata e non esegue correttamente l'invio dei parametri al modello, il modello dovrebbe semplicemente fidarsi di loro e non fare nulla per convalidarli? Dovrebbe convalidarli.

And where do I check permissions of the user to access information?

In MVC questo è posizionato la maggior parte del tempo all'interno del controller. Questo perché le interazioni dell'utente con il modello passano attraverso il controller, il controller è il punto di ingresso. La maggior parte delle persone si ferma qui. Il modello non viene chiamato se il controller vede che non hai i permessi giusti. Di nuovo, se si sostituisce il controller o ne si aggiunge uno nuovo, la nuova implementazione deve proteggere il modello. Se è bug o lo sviluppatore si dimentica, puoi finire per fare una chiamata all'evento modello anche se non dovevi.

Quindi la sicurezza dovrebbe essere applicata sia al controller che al modello. Il modello controlla che sia consentita una chiamata aziendale mentre un controllore controlla che sia consentito un punto di ingresso. Ad esempio, è possibile accedere a un URL in modo corretto se si è connessi o meno (il controller lo consente in entrambi i casi), ma è possibile accedere ad alcune funzionalità da tale URL solo se si è connessi (il modello non ammette ruoli anonimi).

Spero che questo ti sia di aiuto. Come menzionato nelle risposte, MVC ha molti aromi e, a seconda delle applicazioni, delle esigenze, della comprensione degli sviluppatori, del mezzo di accesso (MVC web vs MVC desktop app), ecc., Un certo comportamento potrebbe essere implementato in modi diversi. / p>     

Model View Controller è davvero solo di raggruppare 3 preoccupazioni separate, cioè responsabilità. È un vecchio modello di design creato prima di sapere come interagire con gli oggetti.

View - Logic for displaying things to the user.

Una corretta. Ricorda che potrebbero esserci più di uno di questi.

Model - Database models.

Sì, qualsiasi modello in realtà. Questo è lo stato dei programmi . Dove ricordi le cose che sei, heh, la modellazione. Potrebbero essere solo alcuni oggetti valore come stringhe, interi e quant'altro.

Controllers - logic that deals with moving the info stored in the models to the view and the other way around.

No.

Questo è vero solo per alcune implementazioni di MVC. Ciò significa che assomigli a questo:

Che puoi fare. Ma puoi anche fare:

Qui il controller non sa nemmeno che la vista esiste. "Cosa sa di cosa?" è la migliore domanda architettonica che conosco.

Ci sono molti altre forme di MVC. Se lo studi ti lascia come se un sacco di cose non fossero inchiodate, hai prestato attenzione.

Ciò significa che decidere di utilizzare MVC non significa molto. Devi ancora decidere cosa sa di cosa e come parlarne.

Quando sono nel modello mi aspetto che tutto sia il modo basilare per creare lo stato. Non voglio occuparmi di logica che prende decisioni.

So my question is if I have some functions that help me deal with models, but isn't a model itself, where should I put it?

For example, let's say I have the next models: User, Post, Comment. And I created a function called "Add", and it receives the two arguments: "model name" and "properties" for that model, and the function uses the requested model and doest all the work needed to add it to the database.

Il tuo modello dovrebbe avere un'API di base che consenta di modificarlo. Se è così, allora questo è il modello. Altrimenti. Se questo è un livello di fantasia sopra l'API di base del modello, allora non è proprio il modello.

And is there any good structural pattern you think I should get a look at?

Ebbene si. MVC è il goo primordiale di entrambi gli schemi di architettura e design. È un buon punto di partenza, ma un posto povero in cui vivere.

Prima di tutto lo studio sulla modello di osservatore . Ti insegnerà quali sono realmente gli eventi e spiega perché alcune delle frecce in questi diagrammi non sono le stesse.

Scopri quali sono i principio di inversione delle dipendenze . Aiuta a rendere significative le linee che disegna intorno alle tue responsabilità.

Quando si è pronti per l'architettura leggere su architettura esagonale . È un modo diverso di guardare le architetture stratificate. Un bel variante dell'architettura esagonale è il architettura pulita .

C'è molto altro in cui potrei entrare ma che dovrebbe darti abbastanza da masticare per un po '.

Devi stabilire relazioni con i tuoi modelli. Le relazioni possono essere 1: 1, 1: Molte, molte: 1, molte: molte.

Prendendo in considerazione il tuo esempio: -

1 utente può creare più post

1 post può avere più commenti.

Quindi fondamentalmente quando si codificano le classi del modello dovrebbe essere qualcosa del tipo: -

 /*
   Disclaimer: This is just an illustration. The actual code may differ depending on the technologies or frameworks that you use. 
 */

 class User {
    private String name;
    private String createddatetime;
    ....
    ....
    @OneToMany
    private Collection<Post> posts = new ArrayList<Post>();
 }

 class Post {
   ...
   ...
   @OneToMany
   private Collection<Comments> comments = new ArrayList<Comments>();
 }
 class Comments {
    private String freeText;
 }

Detto questo, veniamo alle tue domande: -

So my question is if I have some functions that help me deal with models, but isn't a model itself, where should I put it?

Questa è la responsabilità del Controller.

Un controller può inviare comandi al modello per aggiornare lo stato del modello (ad esempio, modificare un documento). Può anche inviare comandi alla vista associata per cambiare la presentazione della vista del modello (ad esempio scorrendo un documento).

I controller possono invocare i metodi di servizio che invocano i metodi Dao che istanziano i modelli