Ha senso integrare il backbone.js con ASPNET MVC?

Question

Io non sono un esperto di questi elementi, ma a prima vista mi sembra:

• ASPNET MVC vuole generare i punti di vista e gestire i modelli per un'applicazione sul lato server. Visualizza il browser come un motore di presentazione un po 'stupido, un consumatore delle viste fornite dal server.

• backbone.js vorrebbe generare le viste e gestire i modelli nel browser. Visualizza il lato server come un motore di persistenza basato su REST piuttosto stupido.

Questa sembra una visione semplicistica. Sono sicuro che non è tutta la storia.

Quali sono le reali opportunità per integrare queste due cose? Ha senso farlo? Oppure c'è troppa sovrapposizione tra di loro perché abbia senso?

Mi piace vedere qualche analisi o discussione su questo, se qualcuno può riferirmi.

Answer 1

Anche se non riesco a parlare con backbone.js, posso dirvi che ho usato il knockout con grande effetto combinato con ASP.NET MVC. Ogni applicazione ASP.NET che ho visto fino ad oggi utilizza un mix di generazione di viste lato client e lato server. Ci saranno sempre dei momenti in cui è più conveniente generare viste sul lato server. Prendiamo ad esempio gli elementi dell'interfaccia utente condizionale in base al fatto che un utente sia autenticato o meno, oppure se hanno un'autorizzazione specifica. Potresti non volere che un utente esperto del Web sia in grado di esplorare i tuoi modelli lato client e di elaborare tutte le funzionalità che non ottengono. Certo, potresti aggirare il problema caricando in modo asincrono diversi modelli di client, blah blah, o finendo di scrivere codice lato server per generare i tuoi modelli client-side ... Inoltre se SEO significa qualcosa per te, puoi baciare i template sul lato client (da solo) arrivederci.

Quindi il punto debole, a mio parere, è qualcosa che fa entrambe le cose bene. Nella mia esperienza ho trovato ASP.NET MVC per eccellere in entrambi.

Perché ASP.NET MVC è impressionante

• layout (MasterPages)
• Razor (type-safe opinioni con intellisense bontà)
• ActionFilters (posto incredibile per l'applicazione di convenzioni, come la registrazione, autenticazione , ecc.)
• serializzazione JSON gratuitamente - return Json(model)
• Modello di rilegatura e convalida
• CIO e MVC sono i migliori amici (Win)
• autenticazione + autorizzazione
• sacco di altre cose che non riesco a pensare.

Utilizzando un framework lato client per la generazione di viste tutto quello che ti manca è Razor. Puoi persino sfruttare i layout in una certa misura.

L'approccio che prendo allo sviluppo con ASP.NET MVC è iniziare facendo funzionare l'applicazione sul lato server. Questo ti costringe a pensare a te che vuoi la struttura dell'URL, cosa merita un controller, quali dovrebbero essere le tue rotte.Significa anche che ottieni il vantaggio della sicurezza del tipo e del completamento automatico durante la prima iterazione delle visualizzazioni. Alla fine di questo esercizio hai una soluzione semplice e conforme agli standard (si spera) che funzioni su qualsiasi dispositivo noto all'uomo, di cui Google non ne abbia mai abbastanza.

Quindi ho deciso di adottare un approccio incrementale all'implementazione delle porzioni di funzionalità lato client. Sul lato client scrivo alcuni javascript per dirottare una richiesta che voglio trasformare in una richiesta AJAX e gestire la risposta usando una versione tradotta della vista Razor. Dal lato del server prendo un approccio basato sulla convenzione usando un filtro azione. Questo filtro azioni fa approssimativamente quanto segue:

• ActionResult è un ViewResult?
  • Che cos'è il tipo Accept?
    • HTML - Restituisce una PartialViewResult con lo stesso nome con prefisso "_" dato lo stesso modello di
    • JSON - Restituisce un JsonResult dato lo stesso modello
• È l'ActionResult risultato RedirectToRoute ?
  • Return EmptyResult (o, in alternativa si può restituire l'URL in un JsonResult)

Con questo approccio è possibile aggiungere funzionalità AJAX senza cambiare una sola riga di codice nel controller. Un approccio alternativo è quello di seguire lo Thunderdome Principal e fare in modo che ActionInvoker sia responsabile del wrapping del modello in un tipo di risultato appropriato in base al contesto della richiesta. Non ho ancora capito come la navigazione lato server (reindirizzamenti) si adatti a questo approccio.

Lo spreco nell'iniziare con un'implementazione lato server sta raddoppiando nel codice generazione vista (modello basato su Razor + js). A seconda della quantità di applicazione che si desidera implementare sul client, questo potrebbe o meno essere un problema. Spark è l'eccezione a questo in quanto è possibile ottenerlo a generate client templates per te! Il lato negativo di Spark è che si perde intellisense (c'è un plugin per questo, ma è una schifezza) che non è una perdita insignificante, in più preferisco Razor (è cotto, non ha bisogno di essere configurato, e non sta andando via in qualsiasi momento presto).

Answer 2

Ho usato asp.net mvc KO e bakcbone per diversi progetti e tutto si riduce alla natura del progetto alla fine. Lo stack del server non sarà immediatamente disponibile una volta che i flussi di lavoro inizieranno a diventare complessi o se offri UX a differenza delle semplici applicazioni di data centric data. Quando il tuo progetto coinvolge grandi backbonejs di UX puoi farti arrivare lì. Il lato negativo è che non ci sono linee guida centralizzate ben definite per cui dovrai passare attraverso inferno di blog per fare le cose. Per le app convenzionali puoi attaccare a KO. A proposito ci sono plugin che possono prendere in giro KO per backbonejs. Mi riferisco a bacjbone.modelbinder che devi integrare per te stesso. Cuz MS non si preoccuperà affatto.