Disegnare la linea tra modelli e librerie?

Penso che tu abbia risposto alla tua stessa domanda - I modelli dovrebbero semplicemente includere la logica relativa ai dati di base, e ogni altra funzionalità astratta dovrebbe essere gestita dalle classi della biblioteca (IMO - dovrebbe essere presa con un pizzico di sale, come sono molte definizioni di MVC e simili per il web).

Quindi, per estendere il tuo esempio: la classe User , avrebbe setUsername , getUsername , setPassword , getPassword , validate , destroy , hash , encrypt ecc. Anche se è vero che logIn può essere considerato una funzione correlata ai dati e può essere inserito nel modello (questione di stile e gusto credo), a me sembra più specializzato e lo posizionerei in un altro classe chiamata Authentication , che si occupa di tutti i User correlati, non direttamente legati alla funzionalità dati.

Per riassumere, ritengo che questo sia in gran parte una questione di stile di codifica. Dopotutto, dovrebbe avere senso finché lo sviluppate / mantenete. E, naturalmente, dovrebbe essere ben documentato, quindi nel caso qualcuno erediti detto codice, non si perderebbe mai:)

MVC come tutti sappiamo, è composto da Modello , Visualizza e Tutto il resto .

Dove si adatta l'autenticazione? in tutto il mondo .

È fondamentalmente un livello in cima a MVC, ma poi deve anche tornare in MVC per integrarsi con la vista e il modello.

Authentication è un problema continuo con il modello MVC e con orientamento degli oggetti in generale, hanno praticamente inventato nuovi paradigmi per affrontarlo: uno è programmazione orientata all'aspetto .

La unica cosa certa sugli aspetti, è che Auhentication è uno di loro ; a parte questo, le implementazioni effettive divergono leggermente: la maggior parte concentra sui corpi delle funzioni di iniezione prima o dopo i metodi di altri oggetti. Definire l'ordine delle iniezioni, il punto esatto, (chiamato punti di giunzione ) e lo scopo preciso del codice iniettato è piuttosto discutibile ... e roba da teorici.

Quindi, se ritieni ogni approccio che utilizzi per l'autenticazione sembra incompleto e poco elegante , non sei solo .

Almeno sapere che non esiste una soluzione definitiva dovrebbe rimandare un po 'di vapore: la maggior parte degli approcci che ti verranno in mente sono validi come tutti gli altri . (a condizione che funzionino)

Ti suggerisco di considerare un concetto di design MVC ( Controller vista modello )

I modelli sono per la comunicazione con un database, i controller sono per l'interazione con le azioni dell'utente e Le viste sono per l'interazione visiva con un utente (display, modelli)

Ad esempio: nel tuo esempio, tutte le operazioni relative all'utente avrebbero 3 parti: Controller utente che consisterebbe in: aggiunta, eliminazione, aggiornamento delle informazioni dell'utente (ma accetterebbe solo i parametri che invierebbe direttamente al modello dell'utente che sarebbe responsabile per le effettive comunicazioni (operazioni) con il database: aggiungere un nuovo utente al database (sul base di ciò che i paramenter sono stati inviati dal controller), cancella l'utente dal database, aggiorna le informazioni dell'utente nel database ... E visualizza , sarebbe un modello per la visualizzazione delle informazioni utente, per ottenere parametri per l'aggiornamento delle informazioni utente ecc ...

Ecco perché gli sviluppatori di PHP utilizzano i framework esistenti o ne contraggono i propri. Un'applicazione diventa molto più modulare, molto più semplice per l'aggiornamento, il refactoring ...