Tutti i nuovi progetti Web dovrebbero creare il back-end basato sui set di risultati xml / json? [chiuso]

Non c'è una risposta SÌ o NO alla tua domanda. La decisione di introdurre un secondo livello di riferimento indiretto sotto forma di API xml / json dipende da cosa stai per fare con il tuo progetto.

Come hai detto, in questi giorni molti progetti diventano mobili, tuttavia, non esiste un modo più semplice per fornire funzionalità mobili semplicemente presentando una versione personalizzata della tua interfaccia web? Non posso rispondere ma forse puoi.

Altre domande che potresti chiederti sono: ce ne sono altre che vogliano scrivere clienti alla mia domanda? Se la risposta è sì, allora una API xml / json potrebbe essere una buona soluzione.

EDIT: PS: in qualunque modo tu stia andando, separare la logica di business dal MVC ha la stessa importanza. Un'API ti costringerebbe a farlo, ma anche senza un secondo livello di incapsulamento dovresti riuscire a farlo bene.

Dipende dalla tua applicazione. Molte aziende semplicemente non hanno bisogno di un livello di servizi API Web e possono utilizzare le pratiche MVC standard per offrire pagine renderizzate da controller sottili ben progettati. Questo può essere molto più veloce da creare e più facile da gestire rispetto a qualcosa come un livello di vista scritto interamente in javascript non gestibile (la maggior parte è) che raggiunge la tua API.

La maggior parte dei framework presuppone che la vista sia resa nella stessa applicazione in modo da combattere tale assunto e perdere molte funzionalità "gratuite". La logica aziendale può perdere in entrambi i casi, quindi è una questione se il livello aggiuntivo di astrazione ti dà qualcosa.

No.

XML / JSON sono solo formati di dati.

Ha senso avere una netta separazione tra logica aziendale e presentazione (a meno che non si tratti di un piccolo progetto). Se hai procedure / funzioni / metodi che espongono le operazioni nella tua applicazione, che non sono "contaminate" con argomenti di presentazione (cioè prendono primitive, oggetti business-logic invece di richieste HTTP, eventi GUI, ecc.), È abbastanza è facile esporli in diversi modi: XML, JSON, qualunque sia, e ovviamente puoi invocarli direttamente dai livelli di presentazione applicabili.

Non è necessario forzare una separazione "dura", in realtà non richiede molta disciplina, e anche se hai richiesto progetti separati per altri motivi (ad es. team diversi, ecc.), preferirei utilizzare il backend come "libreria" invece che come servizio, se possibile, l'invocazione del metodo diretto ha meno spese generali in tutti i sensi ed è altamente auspicabile.

Sì, penso che sia davvero sensato ed è un'architettura eccellente. È così semplice restituire JSON / XML al client in modo trasparente dal server: non è necessario scrivere un livello aggiuntivo. I client Javascript consumano facilmente JSON. Hai una netta separazione delle preoccupazioni. È possibile generare codice dal modello condiviso per la convalida in fase di compilazione, se si sceglie. E ovviamente hai la flessibilità menzionata nella domanda di supportare ulteriori clienti, ad es. mobile. Non dimenticare che anche la tecnologia back-end può cambiare. Abbiamo sostituito un back-end .NET per un backend java / spring / tomcat al mio ultimo lavoro.

No, non esporre tutti i servizi aziendali "alla cieca", con l'unica eccezione possibile se la tua app ha un front-end 100% smart-client (vale a dire considera questo solo se NONE del tuo Html dinamico viene reso dal server).

La logica è:

• Questo rallenterà le prestazioni delle schermate di rendering del controller inutilmente a causa dello stack TCP / IP aggiuntivo "hop"
• Crea una superficie più ampia per gli attaccanti - potresti dimenticarti di bloccare i servizi che non stai effettivamente utilizzando.
• L'esposizione dei servizi deve essere eseguita in modo formale (ad esempio dai controller per i client JSON / browser o un insieme formale di servizi di integrazione, ad esempio i servizi Web). Se non lo fai, in un'azienda, potresti trovarti con un gruppo di consumatori dei tuoi servizi di cui non sei nemmeno a conoscenza.
• In molti casi (in qualsiasi caso in .NET), l'esposizione dei servizi JSON a un browser viene eseguita al meglio dal controller MVC, poiché i servizi Ajax sono spesso strettamente accoppiati alle visualizzazioni. Questo non è il posto giusto per esporre i servizi di integrazione (ad es. SOAP / WSE) ad altri sistemi.

In breve, hai ragione a spostare la logica dalle viste e dal controller in un "back-end layer", ma l'accoppiamento tra controller e back-end non è necessariamente attraverso un limite del servizio web.

Con l'aumento dei framework di rendering dell'interfaccia utente lato client Javascript come backbone.js e altri vari trucchi come pjax, questa opzione sta diventando sempre più popolare.

È sempre una buona idea separare la logica di business dai problemi di presentazione.

A seconda del tuo budget / tempo, potresti saltare l'API pubblica (manipolare oggetti di OAUTH è un grande spreco di tempo da solo) e costruire i tuoi controller e visualizzazioni per consumare il set di risultati json restituito dal codice specifico dell'applicazione . Vado con questo approccio da un po 'di tempo, e ripaga prima di quanto mi aspettassi.

Potresti leggere The Clean Architecture , un bel post sul blog di Robert Martin (UncleBob). Alcuni buoni consigli là dentro.

Molto probabilmente sì , se il tuo clients are going to consume Restful HTTP services.

C'è una tendenza crescente nelle applicazioni web / mobile a utilizzare in modo esteso i servizi HTTP con lo scambio di dati formattato json / xml. Quindi, se stai sviluppando su piattaforma .NET, c'è API Web ASP.NET che faciliterà lo sviluppo e fornirà le funzionalità più fondamentali immediatamente.

Anche se sei developing for different platform , i servizi ancora http e il tipo di scambio di dati formattati con dati formattati stanno iniziando a giocare un ruolo importante, e sta diventando sempre più importante spostarsi verso quella direzione.

Ogni volta che ho dovuto riutilizzare uno schermo in un'applicazione web, il nuovo scopo ha richiesto query leggermente diverse e diverse logiche di business. L'idea del riutilizzo è fantastica, ma non l'ho mai vista in quei 12 anni in cui sono stato uno sviluppatore di applicazioni Web professionali. Il tuo chilometraggio può variare.