business logic: lato client vs. lato server

Question

business logic: lato client vs. lato server

#1 da (9 voti)
#2 da (2 voti)

2

Diciamo 3-5 anni fa (più o meno) l'applicazione n-tier sul lato server - e alcuni javascript / html / CSS per l'interfaccia utente erano un approccio di base per lo sviluppo web.

Al giorno d'oggi possiamo vedere che il paradigma dello sviluppo web tradizionale cambia molto. Ogni giorno ho visto sempre più applicazioni che non hanno il lato server in modo tradizionale. Consumano solo alcuni servizi (data-service, auth-service, ecc.) Ma la logica aziendale è posta sul lato client. Inoltre già molti framework javascript creano per semplificare lo sviluppo in base a tale modello (angolare, backbone, ecc.)

Quali sono i principali vantaggi e svantaggi del nuovo modello rispetto all'approccio tradizionale?

design architecture web-development

posta Ph0en1x 15.10.2013 - 02:41

fonte

2 risposte

Leggi altre domande sui tag design architecture web-development

È necessario avviare la variabile da zero (var i = 0) di 'for loop'? [duplicare] utilizzo di doppi puntatori e n puntatori?

score 9 · Answer 1

Ci sono molti vantaggi in questo approccio: -

Reattività, poiché la logica aziendale è nel fat client, non è necessario attendere un round trip sulla rete per ogni interazione.
Sofisticazione: avere tutto il controllo e la logica di livello superiore nel client abilita interfacce utente ricche (ad esempio questo sito o gmail) che semplicemente non sarebbero possibili se ogni interazione richiedesse un round trip sul server.
Scalabilità, tutta questa elaborazione avviene sul tuo dispositivo, usando la tua elettricità. se hai un numero elevato di utenti il risparmio nell'elaborazione lato server è significativo.

Però ci sono alcuni aspetti negativi.

Mancanza di controllo sull'ambiente client. Non sai quale browser su quale sistema operativo o quale dimensione dello schermo e potenza di elaborazione avrà il tuo cliente. L'applicazione potrebbe non funzionare su tutti i client.
Risposta non uniforme. Le librerie client di grandi dimensioni devono essere scaricate e aggiornate di tanto in tanto che saranno relativamente lente, una volta scaricata la risposta è velocissima, gli utenti preferiscono generalmente un tempo di risposta consistente anche se è un po 'più lento.
Javascript: lo adoro o lo odi, sei bloccato con esso come il tuo principale linguaggio di sviluppo. Il tuo codice diventa pubblico che alcune aziende odiano (forse sono imbarazzati dalla loro qualità del codice?).
Sicurezza: il tuo codice server è ora in gran parte solo servizi di database le cui API sono aperte a chiunque stia studiando il tuo Javascript, quindi devi prestare particolare attenzione nel proteggere questi servizi.

score 2 · Answer 2

Oltre a ciò che @James Anderson ha detto, se si sta lavorando su un sistema che utilizza tabelle di database condivise, si desidera evitare di ripetere le regole aziendali sul server e su ogni tipo di client che si sceglie di utilizzare. In alcuni casi è necessario, in quanto il caso è in fase di convalida, ma altre regole aziendali non dovrebbero essere ripetute, se possibile. Il tentativo di replicare le stesse regole in lingue diverse è soggetto a errori. Inoltre, a volte è necessario estrarre diversi dati e trasferire questi dati al client per eseguire la convalida. Questo va contro la reattività.

INMO, la separazione delle preoccupazioni deve essere considerata una priorità nella progettazione quando la reattività non è un problema critico.

Un argomento che ho evitato di fare è "cosa fai con i clienti che disattivano JS?" ...