È possibile o consigliabile creare un sito Web jquery/.NET Service only?

Question

Quello che voglio dire è che la direzione sembra essere quella di fare di più sul client ... Perché non solo un sito web che è solo jquery/HTML sul front end e nient'altro che i servizi Web .NET sul back-end che sono chiamati dai comandi jquery ajax?

È fatto ovunque? Non lo vedo fatto .. come mai? Sembra una soluzione semplice. Non c'è bisogno di trattare con un livello di astrazione ASP.NET ..

Answer 1

È abbastanza possibile. Ho un sito che una volta caricata la pagina iniziale, il server invia solo dati JSON che sono resi sul client. (anche se il server in questo caso esegue php)

Answer 2

Google ha una demo che dimostra questa metodologia a cui ti riferisci. È il Autoshoppe Demo per Google App Engine. Sebbene sia Java, i concetti si applicano anche alle applicazioni .NET.

L'app contiene semplici pagine HTML vaniglia con estensioni .html. Non ci sono tecnologie di visualizzazione lato server per complicare la vita di un programmatore HTML. Le pagine HTML utilizzano JavaScript AJAX per interagire con i servizi Web REST creati utilizzando Spring 3.0, che interagiscono con un archivio dati.

• I dati richiesta viene passato come JSON nella richiesta
• i dati di risposta viene restituito come JSON nella risposta.

Ciò significa che chiunque può creare un'interfaccia utente su questa API oppure è possibile creare un progetto .NET che interagisca con tali dati. REST è una grande architettura per la creazione di servizi estensibili e stratificati.

Penso che la ragione per cui questa tecnica non è ampiamente utilizzata è perché molte persone sono bloccate sulle tecnologie di visualizzazione che incoraggiano gli sviluppatori a utilizzare il markup del fornitore della tecnologia di visualizzazione nell'HTML, come i file ASP (o JSP per Java). È una pratica in circolazione da un po 'perché fondamentalmente gli autori di questi framework sono ingegneri, non progettisti di web e designer di interfacce utente.

Inoltre, è necessario comprendere in modo approfondito REST per vedere i vantaggi offerti da questo metodo e gli sviluppatori più giovani a volte hanno difficoltà con questi concetti.

Se si dovesse affrontare questo in .NET, utilizzando la demo di AutoShoppe come linea guida, molto probabilmente si vorrebbe usare un mapper di oggetti che può convertire il JSON in un oggetto .NET e tornare a JSON. Questo è un approccio molto più pulito rispetto al tentativo di analizzare da solo JSON.

I vantaggi di questo approccio RESTful sono che il contenuto, il comportamento e la presentazione sono completamente separati al 100% dal punto in cui è possibile fornire al programmatore Web i file HTML e lui/lei potrebbe eseguirli completamente al di fuori del. Ambiente NET. I tuoi designer possono quindi utilizzare gli strumenti e concentrarsi sui loro punti di forza, senza dover installare, configurare o eseguire Visual Studio.NET. In realtà, i file sarebbero eseguiti direttamente dal desktop.

EDIT: Forse uno svantaggio è che non c'è molto supporto per questo in molti framework MVC, soprattutto perché è un nuovo concetto. Il ponte tra lato client e lato server deve essere scritto dallo sviluppatore.

Nella demo di AutoShoppe, gli sviluppatori hanno scritto una classe prototipo in JavaScript per gestire la conversione dei dati in JSON prima di inviarli al server e hanno dovuto scrivere codice JavaScript per eseguire il marshalling del JSON in oggetti JavaScript e manipolarli di nuovo in HTML . Sul lato server, utilizzavano un Object Mapper per deserializzare il JSON agli oggetti. La maggior parte della complessità era sul server.

I vantaggi di trasformare il componente lato server in un servizio RESTful al 100% riutilizzabile con cui progettisti e clienti possono facilmente interagire possono superare gli svantaggi, a seconda dello scenario. Un buon esempio potrebbe essere per un servizio in cui i vostri clienti sono incoraggiati a codificare le proprie interfacce utente o avere il pieno controllo sulla whitelabeling dei prodotti. Questo è uno dei molti motivi why I won't use server side view technologies.