Devo implementare BackBone.js nelle mie applicazioni WebForms ASP.NET?

Question

Devo implementare BackBone.js nelle mie applicazioni WebForms ASP.NET?

#1 da (2 voti)

2

Sfondo

Sto cercando di migliorare l'attuale modello di sviluppo delle app Web del mio gruppo. Il nostro schema attuale è qualcosa che abbiamo trovato mentre provavamo a ricche applicazioni web su WebForm ASP.NET (nessuno di noi conosceva ASP.NET MVC). Questo è il modello attuale:

!

LanostraapplicazioneutilizzailframeworkWinForms.
- LenostrepagineASPXsonoessenzialmentesoloHTML,nonusiamoquasinessunWebControl.
UsiamoJavaScript/jQuerypereseguiretuttiinostrieventiUIelechiamateAJAX.
- PerunasingolapaginaASPX,abbiamounsingolofile.js.
- TuttelenostrechiamateAJAXsonoPOST(nonRESTfulaffatto)
LenostrechiamateAJAXcontattanoWebMethodscheabbiamodefinitoinunaseriedifileASMX.
- UnfileASMXperoggettodibusiness.

Perchécambiare?

Vogliorivedereunpo'ilnostropatternperunpaiodimotivi:

StiamoiniziandoascoprirecheinostrifileJavaScriptdiventanounpo'ingombranti.
StiamoutilizzandounmiscugliodimetodipermanteneresincronizzatiinostridatilocaliegliaggiornamentidelDOM.Sembracheimpieghiamotroppotempoascriverecodicepermanteneresincronizzatiglielementiepuòrisultarecomplicatoeseguireildebug.

Holetto Sviluppo di applicazioni Backbone.js e mi piace un molto di ciò che Backbone ha da offrire in termini di organizzazione del codice e separazione delle preoccupazioni. Tuttavia, sono arrivato al capitolo dell'app RESTful, ho iniziato a provare qualche esitazione sull'utilizzo di Backbone.

Il problema

Il problema è che i nostri WebMethod non si adattano veramente al modello RESTful, che sembra essere il modo in cui Backbone vuole consumarli.

Per ora, mi piacerebbe solo affrontare il nostro problema del codice lato client disorganizzato. Mi piacerebbe evitare grosse riscritture ai nostri WebMethods.

Le mie domande

È possibile utilizzare Backbone (o una libreria simile) per ripulire il nostro codice client, senza influire in modo significativo sui nostri WebMethods di accesso ai dati? Oppure provare a usare Backbone in questo modo sarebbe una bastardizzazione della sua destinazione d'uso?

Qualcuno ha qualche suggerimento per migliorare il nostro schema nell'area di organizzazione del codice e dedicare meno tempo alla scrittura del DOM e del codice di sincronizzazione dei dati?

javascript design-patterns webforms asp.net code-organization

posta Walter Stabosz 03.12.2012 - 17:45

fonte

1 risposta

Leggi altre domande sui tag javascript design-patterns webforms asp.net code-organization

Come mantenere le richieste in background in sequenza Modo corretto di vendere prodotti commerciali con piccoli script in GPL? [chiuso]

score 2 · Accepted Answer

Dipenderà in gran parte da come hai architettato e scritto il tuo codice, ma è possibile riadattare l'applicazione per consentire l'uso di Backbone.js (e no, non penso che sia necessariamente una bastardizzazione).

Ciò che devi fare è tradurre le tue chiamate da qualche parte in qualcosa che i tuoi servizi web possano capire. Ci sono potenzialmente due modi per farlo:

Crea un wrapper API sul lato server che invia e riceve chiamate REST. In sostanza, devi creare una classe "API" / "router" con cui l'applicazione Backbone si interfaccia. Questa API converte le chiamate REST in qualcosa che i tuoi servizi web comprendono. Quindi traduce le informazioni dai servizi Web in una risposta RESTful che l'applicazione Backbone comprende. (Funziona molto facilmente se i tuoi WebMethod possono essere richiamati direttamente da altre funzioni sui server (IE - "var foo = bar.GetData ()" o qualsiasi altra cosa.)
Sostituisci i metodi di sincronizzazione di Backbone con i tuoi. È anche possibile sovrascrivere la funzione di sincronizzazione integrata con la tua. In questo modo potrai creare un set di funzioni di sincronizzazione in grado di comprendere il tipo di dati che stai inviando e ricevendo. Ciò tradurrebbe i comandi REST (ottieni, imposta, aggiorna, cancella) dalle applicazioni in comandi conformi ai tuoi servizi web.

Personalmente consiglio di mettere un wrapper attorno al codice lato server se possibile, in modo da poterlo aggiornare in futuro, senza dover rielaborare il codice lato client. Tuttavia, se devi seguire il percorso dell'opzione 2, prova a scrivere il resto dell'applicazione Backbone come se i tuoi servizi web fossero un'API RESTful, in questo modo puoi facilmente sostituire le tue funzioni di sincronizzazione con il vanilla Backbone.Sync una volta hai convertito il tuo server.