JavaScript - Separazione lato client di Model e ViewModel?

Question

JavaScript - Separazione lato client di Model e ViewModel?

#1 da (3 voti)

2

Sto sviluppando applicazioni Web utilizzando l'approccio Model-View-ViewModel con Knockout.js. Dopo aver letto su introduzione originale di MVVM di John Gossman, mi sono reso conto che il mio ViewModel contiene sempre TUTTA la logica dell'app, non solo la logica dell'interfaccia utente, ma tutto.

Ho letto da qualche parte che con Knockout, il modello è considerato il database o generalmente i dati sul server. Ma secondo MVC, il modello contiene anche funzioni che eseguono alcune elaborazioni con tali dati e non sono correlate all'IU.

Quindi mi chiedevo se sarebbe stato ragionevole avere un oggetto Model separato indipendente dall'oggetto ViewModel? L'idea alla base di ciò sarebbe che ViewModel conterrebbe solo la logica dell'interfaccia utente (come previsto da Gossman) e il modello conterrà solo la logica di business (come in MVC), che non ha nulla a che fare con la visualizzazione effettiva. Esempio:

var viewModel = {
    hint: ko.observable("Idle"), //text visible in the View
    buttonClicked: function () {
        this.hint("doing stuff");
        model.doStuff();
        this.hint("done");
    }
};

var model = {
    doStuff: function () {
        //business logic, UI independent
    }
};

Esiste una raccomandazione o "best practice" che può essere derivata dalla definizione del pattern MVVM?

javascript mvc mvvm

posta jaySon 21.07.2016 - 13:27

fonte

1 risposta

Leggi altre domande sui tag javascript mvc mvvm

Come trovare l'evento più rappresentativo per categoria? Come gestire l'elemento xml con CDATA e dati regolari usando SimpleXML

score 3 · Accepted Answer

Stai architettando eccessivamente la tua app?

MVVM è un ottimo modo per organizzare la logica per un'applicazione che altrimenti sarebbe troppo complicata. Ma a volte può essere eccessivo.

Hai detto che finisci per avere tutta la logica del modello nel ViewModel, e questo non sembra che ti dia problemi. Se non c'è alcun motivo pratico per separare View e ViewModel, allora il classico MVC sarebbe sufficiente per la tua app.

Utilizzo di MVVM comunque

Se vuoi affrontare MVVM ora, quello che hai ottenuto finora è un buon punto di partenza. In realtà è simile a ciò che accade nel mio team: la VM viene eseguita per prima (insieme alla vista e alcuni dati fittizi). Quindi una volta eseguito il back-end (il database e l'API), migriamo la logica aziendale da ViewModel al modello.

L'articolo che hai letto che dice che il modello è "il database" semplifica un po 'la questione. Il modello sarebbe il posto, ad esempio, per avere funzioni per calcolare le tasse locali.

Il modello dovrebbe contenere tutta la logica di cui avresti bisogno se avessi intenzione di presentare le informazioni in una vista separata - ad esempio, se stavi per scrivere un sito mobile dedicato, potresti riutilizzare il Modello ma riscrivere il ViewModel.

Il mio suggerimento è provare a separare il Modello e il ViewModel alcune volte, e vedere se inizi a vedere dei vantaggi. Potrebbe essere l'ottimizzazione prematura, ma probabilmente non lo sai fino a quando non ci provi.

Significa che potresti aver bisogno di un ViewModel

Ecco alcuni segni che potrebbe essere il momento per un ViewModel:

Esiste una logica complessa (ad es. condizioni) nella tua vista o grossi blocchi di codice "non in linea".
Stai raccogliendo funzioni nel tuo modello che sono utili solo in determinati contesti (questa pagina ma non quella pagina)
Il tuo controller è ingombrante di codice che non sembra adatto per la tua vista o il tuo modello