Rottura di una classe modello - MVC

4

Non sono sicuro che ci sia una risposta "giusta" o "sbagliata" a questa, ma ero curioso del consenso generale.

Ho un modello utente che attualmente esegue funzioni utente (come il recupero dei dettagli dell'utente dal database, l'inserimento di nuovi utenti nel database, l'aggiornamento dei dettagli dell'utente ecc.)

Questo porta a una classe abbastanza grande.

Esiste un pensiero accettato sulla rottura dei modelli, quando il modello si riferisce già a un tipo di entità? O in questo caso sono ammesse classi grandi?

Al momento, la classe assomiglierà a qualcosa del genere:

    <?php
class Users_Model
{

    public function userExists($user_id)
    {
        //Code to check if user exists
    }

    public function fetchUser($user_id)
    {
        //code to fetch User object from ID...
    }

    protected function fetchUserPassword($user_id)
    {
        return $this->fetchUserValue($user_id, "password");
    }

    protected function fetchUserLowercaseUsername($user_id)
    {
        return $this->fetchUserValue($user_id, "lower");
    }

    private function fetchUserValue($user_id, $value)
    {
        //fetch a user value from the database
    }


    public function logout()
    {
        //code to log user out
    }

    public function doesPasswordMatch($user_id, $password)
    {
        //checks if inputted password matches that which is on record...
    }

    public function createSession($user_id)
    {
        //creates sessions for DATABASE
    }

    private function createCookie($code, $user_id)
    {
        //create cookies for session
    }

}
?>

La mia preoccupazione stava facendo troppe cose (stava eseguendo il recupero delle informazioni utente dal database e gestendo il lato del database della disconnessione e delle sessioni per l'utente).

    
posta Racktash 29.07.2013 - 21:18
fonte

3 risposte

3

ammessa? ...

Vorrei suddividere una classe User in parti nei casi in cui potrebbe essere necessario ridimensionarla in modo veramente grande.

Esempio di analisi del modello (composizione):

User HAS

  • LoginCredentials
  • ContactInfo
  • Favorites
  • Friends
  • Roles
risposta data 29.07.2013 - 22:15
fonte
3

Chiediti se la classe ha più di una ragione per cambiare.

Secondo la spiegazione di Bob Martin del principio di responsabilità singola:

As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

L'esempio parla della separazione dei cosmetici da sostanziale, ma si applica a qualsiasi altro due o più dubbi, come logica aziendale, persistenza, registrazione, formattazione, ecc.

Se pensi che la tua classe (modello o meno) abbia più di una ragione per cambiare, allora dividi.

    
risposta data 29.07.2013 - 22:42
fonte
0

Tutto si riduce alla separazione delle preoccupazioni e al principio di responsabilità unica (SRP). Ovviamente la domanda è come appare nella pratica, che è quello che stai chiedendo. Avendo lavorato con MVC per molti anni questi sarebbero i miei suggerimenti:

1) Normalmente considero SRP, come applicato ai modelli, il significato di essere responsabile del recupero e del salvataggio dei dati. Ciò significa anche che, in pratica, diventano responsabili per la pulizia e la convalida dei dati perché entrambe queste cose devono accadere prima che i dati vengano salvati. Quindi, se il tuo modello ha funzionato con una tabella (la tabella dell'utente) ed entrambi i dati recuperati e salvati, allora direi che sei sulla strada giusta. Quindi quelle prime 5 funzioni sono perfettamente ragionevoli da una prospettiva SRP.

2) Considererei la disconnessione / l'accesso come una responsabilità separata. L'autenticazione dell'utente ha un proprio complesso insieme di regole: gli utenti possono essere disattivati, il loro account non può essere verificato, la loro iscrizione potrebbe essere scaduta, potrebbero provare ad accedere a una parte limitata del sito, ecc. Il risultato è che l'autenticazione dell'utente è la propria lattina di vermi e merita la propria classe. Nei miei sistemi ho un oggetto utente responsabile del recupero / aggiornamento dei dati dell'utente, ma poi ho una classe "loggata" responsabile di tutto ciò che ho appena menzionato. Non sorprende che la classe registrata utilizzi la classe utente per recuperare i dati dell'utente e quindi dispone di un proprio set di funzionalità per determinare se un determinato accesso è valido.

3) Nel caso che ho descritto, la classe registrata e quella utente finiscono inevitabilmente per essere strettamente correlate e spesso si affidano a vicenda. Quindi è necessario prestare attenzione per assicurarsi che non finiscano troppo legati tra loro e per evitare la duplicazione del codice. Come regola generale, lascio che la classe utente si attacchi al recupero dei dati. Pertanto, la classe registrata potrebbe utilizzare la classe utente per recuperare la password dell'utente oi relativi ruoli assegnati, ma in seguito determinerà se una password in entrata è valida o se l'utente è autorizzato a effettuare il login dati i dati correnti dall'oggetto utente. La classe registrata può essere o meno responsabile della persistenza della sessione degli utenti: ciò dipende dall'architettura, sebbene idealmente la classe registrata non interagisca direttamente con il meccanismo di persistenza della sessione. Invece funzionerebbe attraverso una sessione di sessione generica.

4) In qualche misura l'esecuzione corretta di SRP è più un'arte che una scienza. Sai che sta funzionando bene quando a) ricevi input da qualcun altro che lo ha fatto per un po 'o b) lo usi da molto tempo e lo metti alla prova. In una certa misura sai se il tuo codice funziona correttamente o meno di quanto effettivamente lo usi.

    
risposta data 18.11.2016 - 23:16
fonte

Leggi altre domande sui tag