Mantenimento del modello lato client e lato server in sincronizzazione in ZPS

Generalmente non li si mantiene sincronizzati in questo modo, a meno che non vi sia un motivo per farlo. La tua intera premessa è imperfetta. La maggior parte della logica di dominio in una SPA, come qualsiasi altra applicazione, dovrebbe essere nel server. Solo la logica relativa all'interfaccia utente deve essere nel client.

Modifica:

Quindi, per essere chiari sulla terminologia. Suppongo che quando dici "logica di dominio" intendi la logica di business principale dell'applicazione, la cosa che rende l'applicazione più di semplici operazioni CRUD sulle risorse. Potrebbe anche essere che l'applicazione abbia solo bisogno di memorizzare, recuperare, aggiornare ed eliminare alcuni dati, nel qual caso suppongo che tutta la "logica" sia nel client.

Ma immagina un semplice sistema di acquisto in cui hai articoli di inventario e gli utenti sono in grado di aggiungere articoli a un carrello della spesa per l'acquisto. Immagina quindi che devi sapere se un articolo è in stock o esaurito e se è esaurito il tuo caso d'uso particolare non consente l'acquisto di un articolo esaurito. In questo scenario non penso che faresti la cosa giusta se non avessi questo requisito per controllare la logica nel tuo back-end.

Desidererebbe disattivare il pulsante "Acquista ora" sul client se l'articolo era esaurito, ma consentendo al back-end di elaborare un acquisto per l'articolo esaurito semplicemente perché un adolescente intraprendente ha deciso di presentare una richiesta POST che usa il ricciolo sembra molto sbagliata per me.

Il motivo per il cliente di sapere che l'articolo è esaurito è diverso dal motivo per cui il back-end lo conosce. Il client deve saperlo per disabilitare un pulsante, ma il back-end deve conoscerlo per evitare addebiti errati.

Il modello del client dello stato del sistema potrebbe includere solo un valore booleano acquistabile se è tutto ciò che è necessario, mentre il modello del server potrebbe dover prendere in considerazione una vasta gamma di ragioni, non solo se l'articolo è disponibile o meno - forse l'articolo non è spedibile nella posizione dell'utente corrente o forse l'utente corrente ha un coupon del 35% nel suo account e il margine sull'articolo è inferiore al 35%. È probabile che le ragioni per cui un articolo sia acquistabile o meno è più complesso per il server rispetto al client ed è molto improbabile che un sistema aziendale possa consentire la messa a disposizione della logica aziendale a chiunque possa scaricare i file JS per il sito (ogni visitatore!).

Forse il server in quel caso rimuove semplicemente l'elemento dall'elenco dei risultati in una query per gli articoli acquistabili. Il cliente non può per definizione applicare alcuna logica del dominio aziendale a questo elemento perché non sa che l'elemento esiste in primo luogo.

Che cosa succede se si desidera successivamente distribuire un'applicazione mobile nativa? Hai intenzione di ricreare tutta la tua logica di dominio aziendale in ogni nuovo cliente? Cosa succede se il sistema è diventato così grande che esistono centinaia di regole?

Uno degli aspetti chiave degli sviluppatori di software esperti dovrebbe essere che ci possono essere e saranno più modelli in un sistema.

Ho una soluzione brutta ma funzionante a questo problema. Ho trovato questo post mentre cercavo uno migliore, ma posterò il mio per ispirare qualcuno. Non sono sicuro di come funzionerebbe al di fuori di PHP. Sul retro usiamo questo:

class BaseModel // All models extend this class
{
    // Returns an object with each property set to its own name as a string
    /* @return static */
    public static function getNameObject()
    {
        $obj = (object) get_class_vars(get_called_class()); // Note: Avoids calling constructor
        foreach (get_object_vars($object) as $key => $value) {
            $object->{$key} = $key;
        }
        return $obj;
    }
}

class User extends BaseModel
{
    public $id;
    public $name;
}

Poi ho inserito PHP nei miei file JavaScript:

<?php $u = User::getNameObject(); ?>

var user     = getUserFromServer();
var userId   = user.<?=$u->id?>;
var userName = user.<?=$u->name?>;

In questo modo posso usare il comando Refactor dell'IDE per modificare il nome di una proprietà di un modello e anche tutto il codice front-end viene aggiornato. Tutti i file * .js.php vengono eseguiti per diventare file * .js durante il processo di compilazione in modo che possano essere pubblicati come normali JavaScript statici.