Architettura per web e client mobili

Naviga le tue risposte
4

L'applicazione su cui lavoro ha bisogno di un'interfaccia web (ASP.NET MVC) e interfacce mobili (Android / IPhone native). Le funzionalità per le applicazioni mobili e l'applicazione Web potrebbero non sovrapporsi (alcune funzionalità sono simili, altre sono diverse)

Al momento, sto pensando a 2 modi per strutturare le applicazioni come di seguito:

Per l'approccio top , è sufficiente un solo server Web che server sia i client Web sia quelli mobili. Mobile comunicherà con il server tramite Json (serializzato da ASP.NET MVC). Il livello di servizio è semplicemente una libreria di classi semplice a cui fare riferimento tramite il livello Web

  • Pro
    • Più veloce, poiché non esiste una comunicazione cross-machine tra web e livello di servizio
    • Più semplice
  • Contro
    • Sicurezza? Qui ci sono problemi di sicurezza?
    • Meno flessibile durante il ridimensionamento (è possibile ridimensionare sia il livello Web sia il livello di servizio come un'unica unità).

Per l'approccio bottom , sono necessari un server Web e un server applicazioni (per API WCF / Web). Mobile comunicherà direttamente con il server delle applicazioni tramite Json

  • Pro
    • Può proteggere separatamente server Web e applicazioni, ulteriore livello di protezione sul livello dell'applicazione. Ma il server delle applicazioni è comunque esposto al cellulare giusto?
    • Può scalare in modo indipendente server Web e applicazioni
  • Contro
    • Più lento
    • Più complicato a causa dell'API WCF / Web nel mezzo

È la prima volta che faccio l'applicazione sia per il Web che per i dispositivi mobili in questo modo. Quale approccio è comunemente usato in questo scenario? L'utente tende a privilegiare l'approccio bottom, ma penso che in questo caso potrebbe essere eccessivo seguire l'approccio bottom

    
posta Phuong Nguyen 04.04.2015 - 19:37
fonte

1 risposta

5

Il problema principale che vedo è che con l'approccio principale , il tuo sito web deve essere in grado di accettare richieste da dispositivi mobili, al contrario dei servizi. Sembra che qualcosa del sito non debba preoccuparsi. In particolare, implica che il tuo sito web ha una serie di logiche "pass-through" per duplicare l'API dei servizi o che il sito web fornisce un'API diversa da quella dei servizi (probabilmente un po ' di entrambi). Ad ogni modo, questo è un enorme problema di manutenibilità. Inoltre, aggiunge un ostacolo in più (e il potenziale collo di bottiglia) per le richieste mobili di passare attraverso, rispetto a parlare direttamente con i servizi.

Le affermazioni sul bisogno di uno o due server in ogni caso sono davvero un problema ortogonale: puoi mettere il sito web ei suoi servizi sullo stesso server, se lo desideri (l'ho fatto molte volte nel mio lavoro). Che tu lo faccia o no, non ha molto a che fare con il fatto che il client mobile stia parlando o meno alla tua pagina web o ai tuoi servizi. Mi aspetto che questa decisione abbia più a che fare con (come hai sottolineato) la sicurezza o la complessità, o forse con la scalabilità (cioè se i colli di bottiglia sono nei tuoi servizi o nel tuo sito web). Ma per un sito web sufficientemente grande / complesso / importante, credo che tutti questi fattori si appoggino all'utilizzo di macchine separate.

Pertanto, consiglierei l'approccio bottom.

    
risposta data 06.04.2015 - 00:02
fonte

Leggi altre domande sui tag

Design della tabella delle notifiche? MVC - Verifica dei dati nel modello o nel controller?