La logica aziendale appartiene davvero al server?

10

Uno stack tipico per un'applicazione Web è un database, un server con codice lato server e un utente con un browser con HTML / CSS / JavaScript.

Prima di AJAX esteso, MVC in cui il controller era il codice lato server rullato. Un server ha dovuto indirizzare le richieste di risposta per le pagine Web dinamiche (ad esempio, soluzioni html basate su modelli come JSP e ASP). Il server per coordinare le chiamate al database e decidere quale pagina dinamica utilizzare per rispondere alla richiesta di pagina. Il risultato di tutto questo è che il server ha finito per contenere la logica di business, anche se la logica di business non è strongmente legata all'idea di servire le pagine.

Ora che stiamo passando a "Web 2.0", un server server pagine statiche che utilizzano JavaScript per riempirsi e modificare ciò che stanno presentando. Il può essere nel JavaScript. Il JavaScript implementa spesso un servizio RESTful che significa che sta specificando la query del database.

Quindi il server è in grado di servire i file effettivi e rispondere alle chiamate AJAX. E rispondere alle chiamate AJAX è semplicemente gestione delle sessioni e sicurezza. E in realtà, ciò che un utente dovrebbe essere in grado di vedere sono i dati che dovrebbero essere specificati nel database.

Quindi, da lì, il server dovrebbe essere relegato nel ruolo di uno stupido intermediario che solo occasionalmente fa qualcosa di simile a inviare un'e-mail o sparare da un webservice? La logica aziendale potrebbe vivere in JavaScript (quando non è segreta) o vivere in stored procedure quando lo è?

Avrà senso magari combinare anche server e database o creare soluzioni ERP come la funzione SAP come server?

    
posta Joe 18.10.2011 - 01:53
fonte

4 risposte

14

La logica aziendale deve quasi sempre essere eseguita su un server che controlli, per motivi di sicurezza. Se per "server" si intende "server web", quindi sono d'accordo, non è necessario avere quasi alcuna logica di business. Tuttavia, è quasi sempre necessario un server delle applicazioni con la logica aziendale, che si trovi all'interno di un database o di un server Web o che sia separato e chiamato dal server web.

Esistono applicazioni del mondo reale in cui il server Web non fa altro che esporre l'API del server applicazioni tramite servizi Web o JSON.

Anche prima di Web 2.0 e AJAX non è stata considerata una pratica ottimale per combinare la logica di business con le pagine ASP. È stato considerato migliore avere una logica di business indipendente e avere la parte server della logica di presentazione in ASP, JSP o altro. Quindi il vero cambiamento dal web 2.0 è che il livello di presentazione può essere interamente in javascript. Preferisco, personalmente.

    
risposta data 18.10.2011 - 02:12
fonte
6

The JavaScript often implements a RESTful service meaning that it is specifying database query.

Questo è dove ti sei sbagliato. REST è non CRUD.

Le risorse esposte da REST non sono i record del tuo database; sono oggetti completamente gestiti che si comportano secondo la tua logica aziendale. Quando il server riceve un POST o PUT, non dovrebbe solo validare e memorizzare. Deve eseguire tutto ciò che è appropriato per l'applicazione.

Semplice esempio: un'app di tipo twitter riceve i tweet come messaggi POST su un determinato contenitore. Il server analizza quindi il contesto ("chi sei?", "Quale canale è questo?") E il contenuto ("eventuali hashtag?", Indici di testo, ecc.) E memorizza tutto ciò nelle rispettive code. Probabilmente aggiunge un riferimento direttamente a tutti i tuoi follower.

Questo è molto lavoro che va oltre la semplice aggiunta della risorsa al contenitore, è tutto definito dalla logica aziendale. E appartiene al server.

    
risposta data 18.10.2011 - 03:00
fonte
2

Le mie preoccupazioni in merito a questo approccio potrebbero essere dovute a un fraintendimento del tuo design, quindi non esitare a spararmi.

tuttavia, pensa alla scalabilità, alla manutenibilità e alla sicurezza del prodotto.

Se il tuo prodotto cresce in modo massiccio, il database diventa il collo di bottiglia, quindi mentre "performance" suggerisce di inserire la business logic nelle stored procedure, carica ulteriore CPU sul server del database, anticipando il giorno in cui il server raggiunge la capacità massima. A differenza dei server Web, i database ACID non si adattano facilmente utilizzando l'hardware parallelo. Se il tuo prodotto non avrà mai successo, questo non è un problema.

Il pensiero di mantenere la logica di business in javascript in esecuzione su webbrowswers, dove diversi browser richiederanno javascriopt diversi, più versioni di browser, ecc ... Perché rendere questo problema più complicato di quanto non sia già?

Come ha detto Javiar, però, usare un approccio REST come API di database per il tuo prodotto non è davvero ragionevole. Il vantaggio di un'interfaccia REST è che altre persone penseranno a modi diversi di utilizzare e interrogare l'interfaccia REST. Tuttavia, si tratta di risorse di business logic post pubblica e non di risorse di record di tabella di basso livello. L'idea di rendere disponibili query di livello così basso sull'API HTTP sembra un incubo per la sicurezza.

    
risposta data 18.10.2011 - 03:08
fonte
2

Mentre ci sono molte scuole di pensiero su questo, e certamente nessuna strada può essere definita "la strada giusta" universalmente, mentre tutte le altre sono "nel modo sbagliato" universalmente, ci sono una serie di ragioni per isolare la logica aziendale lato server e accedere a tali oggetti e servizi tramite un servizio RESTful.

La risposta breve è che si tratta principalmente di gestione del rischio, monitoraggio e miglioramento delle prestazioni.

In dettaglio:

Il motivo principale numero 1 è la sicurezza. Ai client non dovrebbe mai essere affidato il compito di inviare qualcosa di diverso dalla spazzatura al server, e mantenendo gli aspetti relativi alla sicurezza lato server, si isola il potenziale rischio di un utente canaglia che danneggia il sistema. Ricorda, Javascript è completamente client-side, e banalmente modificabile, quindi NON PUOI FIDARTI DELL'OUTPUT.

La ragione numero 2 è la separazione delle preoccupazioni. Il tuo programmatore javascript potrebbe non essere un esperto di sicurezza e il tuo guru della sicurezza potrebbe non essere così bravo su Javascript. Isolando la logica di business dalla logica di presentazione, si evita di superare questi problemi, dato che al javascript non sarà consentito accedere alle risorse oltre i livelli di autorizzazione e ricevere errori, la cui gestione è all'interno del previsualizzatore di script. Allo stesso modo, il responsabile della sicurezza non eseguirà il debug di Javascript per vedere come viene mantenuta la sicurezza.

Il motivo numero 3 è la prestazione. La logica aziendale può potenzialmente richiedere risorse server e database. Mantenendo tale logica isolata dagli elementi dell'interfaccia utente, è possibile ridimensionare solo quella parte dell'applicazione, rendendo molto più semplice affrontare i colli di bottiglia. Inoltre, è molto più semplice isolare quale processo aziendale sta caricando il tuo sistema oi back-end del database se i processi di business sono eseguiti sul server.

Un corollario è che spesso diversi processi aziendali utilizzano gli stessi dati e quindi è possibile implementare la memorizzazione nella cache sul lato server per ridurre il carico complessivo del sistema che potrebbe non essere possibile / sicuro per consentire l'accesso al codice lato client.

Infine, proporrei che per mantenere gli standard ACID, Business Logic abbia davvero bisogno di essere sul server. Ricordo di aver mantenuto un prodotto di fatturazione eseguito nel browser web, con solo una connessione al database del server. Se la fatturazione giornaliera (che potrebbe richiedere un'ora o più in una buona giornata!) È stata interrotta, ad esempio dal fatto che il browser è stato chiuso o si è bloccato, potrebbero essere necessarie diverse ore per risolvere il disordine creato dal database, che è stato lasciato in uno stato incoerente. Ricorda che questo comportava anche carte di credito, quindi i record di fatturazione dovevano essere controllati anche dal processore!

La logica aziendale lato server è in gran parte banale per garantire gli aggiornamenti ACID, poiché esistono framework per qualsiasi lingua per mantenere le transazioni, a livello di applicazione o di database. Se lo fai tramite più aggiornamenti da un client web ... a un certo punto otterrai uno stato incoerente e probabilmente avrà conseguenze sulla tua applicazione.

Mentre può essere allettante pensare ai servizi RESTful semplicemente come un modo per accedere al database, non dovresti cadere in questa trappola, poiché è una buona ricetta per il disastro. Il modello di oggetto che esponi tramite un servizio RESTful può essere correlato al tuo database, ma in realtà dovrebbe incapsulare la tua logica di business invece di utilizzarlo come motore CRUD.

    
risposta data 18.10.2011 - 03:34
fonte

Leggi altre domande sui tag