Cosa devo considerare al momento di decidere se utilizzare un back-end del servizio Web al posto del tradizionale MVC?

Question

Cosa devo considerare al momento di decidere se utilizzare un back-end del servizio Web al posto del tradizionale MVC?

#1 da (5 voti)
#2 da (1 voti)
#3 da (0 voti)

5

Stiamo cercando di decidere quale architettura utilizzare per un'imminente applicazione web che alla fine avrà anche una porzione mobile. Il nucleo del progetto è un'applicazione web di social networking e molto probabilmente la porzione mobile avrà un sottoinsieme limitato della funzionalità web.

Le due opzioni che stiamo esaminando sono un servizio web back-end completo o l'uso di un framework MVC tradizionale per l'applicazione web e quindi lo sviluppo di servizi Web sul lato per l'applicazione mobile più tardi.

Alcuni argomenti per il solo percorso del servizio web sono che sarebbe "più semplice", in quanto dovremmo creare solo un servizio web invece di creare sia un servizio web per la porzione mobile, sia funzioni / chiamate di database aggiuntive per l'applicazione web. Usando questo metodo, l'applicazione web recupererà i dati dai servizi web usando javascript, che genererebbe la pagina html (sembra un po 'come ciò che fa un framework MVC tradizionale, ma in questo modo richiederebbe tutto in javascript).

Non mi sento bene all'idea di utilizzare i servizi Web solo perché non ha senso per me, ma ho difficoltà a chiarire i miei problemi con esso.

Quindi, che cosa dovrei prendere in considerazione quando cerco di utilizzare un back-end completo per il nostro servizio web anziché il tradizionale MVC con i servizi Web disponibili solo quando necessario per la parte mobile dell'app?

Sto cercando una risposta esauriente a questa domanda, non molte risposte ognuna contenente una parte della risposta.

programming-practices web-development

posta kurisu 12.05.2012 - 04:45

fonte

3 risposte

Leggi altre domande sui tag programming-practices web-development

MVVM - finestre secondarie e contesti dati Strumenti di analisi statica per rilevare schemi architettonici

score 5 · Answer 1

Se implementato correttamente, potresti essere in grado di avere entrambi i mondi. Quando si accede al percorso del servizio Web, è possibile che si stia inviando la versione json dei modelli che si intende utilizzare per il rendering delle viste MVC con altro.

Per la versione web dovresti creare il tuo html da qualche parte. Penso che si possa fare questo principalmente lato server o farlo usando una qualche forma di template lato client javascript. Il dato / modello richiesto sarà lo stesso.

Se il percorso del servizio web significa SOAP, non sarei d'accordo.

Perché non rendere l'applicazione Web mobile in grado? Potresti finire per non aver bisogno di un'app mobile nativa ...

score 1 · Answer 2

Sembra che l'approccio tipico di MVC sia quello di utilizzare esattamente un modello, un controller e una vista tutti legati in modo specifico a un determinato tipo di pagina.

Ma il punto principale di separare queste preoccupazioni è risolvere problemi esattamente come questo. Dovresti essere in grado di avere un modello e un controller che operano su due diverse viste, la tua vista mobile e la tua vista web. O almeno un modello condiviso.

La cosa del servizio web richiede che tu abbia degli sviluppatori back-end in grado di fornire dati in un modulo facile da analizzare agli sviluppatori front-end che sanno come manipolare stringhe, dati e manipolazione DOM, ma se non lo fanno ho esperienza in questo, non sono sicuro che mi fiderei di loro per sapere che sarà più facile. Sarei un po 'diffidente perché mette tutto il peso della struttura e dell'organizzazione sul front-end, che le persone tendono a essere cattive nel strutturare e organizzare. Se è un'app abbastanza semplice mi sembrerebbe ragionevole.

score 0 · Answer 3

I fattori che spingono verso un'interfaccia di servizio unificata includono un modello di dati complesso, necessario per applicare coerentemente le regole aziendali o di sicurezza, incapsulare modelli di dati da lunghi cicli di aggiornamento o avere molti diversi tipi di applicazioni client che condividono dati. Il limite dei servizi Web può anche essere un utile limite organizzativo in team più grandi: alcuni sviluppatori si concentrano sull'API mentre altri creano applicazioni su di esso.

Nel tuo caso, penso che l'ibrido sarebbe la scelta migliore. Sembra che la maggior parte delle funzionalità si trovino sul sito Web e sarebbe un lavoro extra costruire il sito su un'API costruita principalmente per l'applicazione Web.

Come punto di chiarimento, puoi utilizzare MVC con i servizi web. Nel client si scriverebbero oggetti di accesso ai dati che comunicano con il servizio Web e quindi si costruiranno i controller in cima a quelli per gestire l'interfaccia utente. Dal punto di vista dell'API, le interfacce dei servizi Web traggono vantaggio dall'applicazione di MVC. È possibile supportare più protocolli utilizzando visualizzazioni alternative, come JSON, SOAP, RMI, Avro, mentre si condivide un modello comune.