Javascript MVC in linea di principio

1

Supponiamo di voler implementare MVC in JavaScript. Non sto chiedendo dei framework MVC. Ti sto chiedendo come costruirlo in linea di principio .

Consideriamo una pagina di ricerca di un sito di e-commerce, che funziona come segue:

  • L'utente sceglie un prodotto e i relativi attributi e preme un pulsante "cerca".
  • L'applicazione invia la richiesta di ricerca al server, riceve un elenco di prodotti.
  • Applicazione visualizza l'elenco nella pagina Web.

Penso che il Modello detenga un Query e un elenco di Product oggetti e "pubblica" tali eventi come "aggiornamento di query", "elenco di prodotti aggiornati", ecc. > Il modello non è a conoscenza di DOM e server, o ovviamente.

Visualizza contiene l'intero albero DOM e "sottoscrive" gli eventi Modello per aggiornare il DOM. Inoltre, "pubblica" eventi come "utente ha scelto un prodotto", "utente ha premuto il pulsante di ricerca" ecc.

Controller non contiene alcun dato. Si "abbona" agli eventi Visualizza , chiama il server e aggiorna il Modello .

Ha senso?

    
posta Michael 14.05.2012 - 22:00
fonte

2 risposte

1

Ciò che dici ha senso ed è l'approccio utilizzato nei framework HTML5 come Sencha Touch 2 (http://www.sencha.com/products/touch/).

MVC è un pattern e non è legato a nessun linguaggio specifico, framework o libreria di classi. Quindi è possibile utilizzarlo anche con Javascript, indipendentemente dalla tecnologia specifica utilizzata.

    
risposta data 30.05.2012 - 17:19
fonte
0

Ricorda che l'idea alla base di un pattern come MVC è semplificarti la vita. Se si avvia un jaxing nel contenuto statico per ramare i quadrati laterali del client nei triangoli MVC, non lo si sta realmente facendo. Abbiamo già le nozioni di base sul front-end, come l'API DOM che già gestisce l'albero DOM, coperto. Usa MVC come livello di astrazione di livello superiore per rendere il codice più leggibile e più facile da modificare e implementare. Se è già coperto dall'API DOM o anche dal core JQuery, ti consigliamo di implementarlo a un livello troppo basso perché sia più utile di ostacolo, IMO.

Penso che sul front-end abbia più senso pensare in termini di come MVC può essere utilizzato per applicare a tipi di widget dell'interfaccia utente piuttosto che un modo per fornire e gestire tutto il contenuto HTML.

Quindi immagina una casella combinata che carichi pigro il contenuto quando fai clic su di esso.

Quindi hai un modello con i metodi per comunicare con il server per ottenere i dati e elaborarli in qualcosa che è facile per il rendering della visualizzazione. Mi fermerei prima di tutto convertendo una serie di elementi in LI sul modello e lasciandolo gestire dalla vista. Il modello attiva gli eventi al termine della preparazione / aggiornamento / elaborazione dei dati.

Hai una vista che gestisce il rendering / re-rendering degli elementi di elenco all'interno delle tue caselle combinate e gestisce anche le informazioni dell'interfaccia utente come completamento automatico / corrispondenza nella casella di testo e attivazione di livello app (non DOM - si traduce quelli) quando vengono selezionati nuovi articoli o si fa clic su una casella non caricata per indicare la necessità di nuovi dati. La vista stabilisce anche il contesto (a quale casella combinata viene applicato un utente).

Il controllore prende le decisioni rilevanti per l'app. Quindi, quando si fa clic su una nuova combo, il controller indica cosa devono chiudere tutte le altre combo. Penso che ci sia una variazione su questo, ma ha più senso per me quando il modello e le viste devono passare attraverso il controller piuttosto che ascoltare o chiamarsi direttamente.

Quindi una vista rileva che una nuova combo è stata cliccata e attiva un evento che il controller ascolta. Il controller determina che i dati sono necessari e attiva un evento che il modello ascolta. Il modello carica ed elabora i dati necessari e, una volta terminato, attiva un evento completato che il controller ascolta. Quindi il controllore consegna i dati alla vista in modo che la vista possa convertirsi in LI e rilasciarli nella casella combinata appropriata.

Ora, non lo amo come una triade di oggetti. Ha più senso per me che ci sia un oggetto box combo genitore che agisce essenzialmente come un controller con un modello aggregato (se necessario) e oggetti vista / UI all'interno. L'oggetto casella combinata padre gestisce anche lo stato e mantiene l'inventario di tutte le varie caselle combinate di cui è responsabile, il che era più una responsabilità della vista nel modello a tre colonne. Quello che mi piace di questo è che è più facile dare un senso all'interazione con altri oggetti e l'oggetto box combo stesso ottiene tutti gli eventi cancellati da esso, rendendoli accessibili ad interessi esterni come un logger di debug o un altro widget UI che deve reagire alla selezione di una casella combinata.

    
risposta data 30.05.2012 - 21:07
fonte

Leggi altre domande sui tag