La logica di business 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 estendere AJAX, MVC in cui il controller era il codice lato server rullato. Un server ha dovuto instradare le richieste di risposta per le pagine Web dinamiche (ovvero 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 ciò è che il server ha finito per contenere la logica aziendale, anche se la logica aziendale non è fortemente legata all'idea di servire le pagine.

Ora che ci stiamo spostando su "Web 2.0" un server server pagine statiche che utilizzano JavaScript per riempirsi e cambiare ciò che stanno presentando. Può essere nel JavaScript. JavaScript implementa spesso un servizio RESTful che significa che sta specificando la query del database.

Quindi il server è lasciato ai ruoli di servire i file effettivi e rispondere alle chiamate AJAX. E rispondere alle chiamate AJAX è semplicemente una gestione della sessione e fornire sicurezza. E davvero, ciò che un utente dovrebbe anche essere in grado di vedere sono i dati che dovrebbero essere specificati nel database.

Quindi da lì, il server dovrebbe essere relegato al ruolo di un intermediario stupido che solo occasionalmente fa qualcosa come inviare un'e-mail o attivare un servizio web? La logica di business potrebbe vivere in JavaScript (quando non è segreto) o vivere in stored procedure quando lo è?

Avrà senso anche combinare server e database o far funzionare le soluzioni ERP come SAP come server?

Risposte:


14

La logica aziendale deve quasi sempre essere eseguita su un server che controlli, per motivi di sicurezza. Se per "server" intendi "web server", allora sono d'accordo, non è necessario avere quasi alcuna logica aziendale. Ma hai quasi sempre bisogno di un server delle applicazioni con la logica aziendale, che si trovi all'interno di un database o di un server Web o 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 delle applicazioni tramite servizi Web o JSON.

Anche prima del Web 2.0 e di AJAX non era in realtà considerata una buona pratica mescolare 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 rispetto al web 2.0 è che il livello di presentazione può essere interamente in javascript. Preferisco quello, personalmente.


Bene, sì, sono d'accordo che la logica aziendale non dovrebbe essere in un ASP. Questo è il punto di MVC.
Joe,

Questa risposta è di quasi due anni fa e ora cose come SproutCore sono di gran moda. Sul sito Web di SproutCore, dichiarano esplicitamente che l'obiettivo è spostare la logica aziendale nel browser (vedere: sproutcore.com/about ). Quindi ... lo stato del web è cambiato ora? La logica aziendale sul client (in particolare tramite JS nel browser) è ok o forse preferibile?
JoeCool

@JoeCool SproutCore esisteva allora. E le considerazioni sulla sicurezza di mettere la logica di business sul client non sono cambiate. Ma non tutte le applicazioni presentano molti problemi di sicurezza. Inoltre, "all rage" sembra abbastanza esagerato per SproutCore. Ma la fattibilità di fare di più sul client ha continuato ad aumentare, tranne per il fatto che i dispositivi mobili hanno continuato a guadagnare importanza e rimangono impegnativi dal punto di vista delle prestazioni per molte applicazioni.
ps

@psr Concesso - ma sembravi semplicemente spazzare via usando la logica di business nel client, quando in realtà almeno alcune tecnologie popolari oggi stanno andando distintamente in quella direzione.
JoeCool

6

JavaScript implementa spesso un servizio RESTful che significa che sta specificando la query del database.

Questo è dove hai sbagliato. REST non è CRUD.

Le risorse esposte da REST non sono i record del 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 archiviare. Deve eseguire tutto ciò che è appropriato per l'applicazione.

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

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


2

Le mie preoccupazioni con questo approccio potrebbero essere dovute a incomprensioni del tuo design, quindi sentiti libero di abbattermi.

tuttavia, pensare alla scalabilità, alla manutenzione 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 logica di business nelle procedure memorizzate, aumenta il carico della CPU sul tuo server di database, anticipando il giorno in cui il server raggiunge la capacità massima. A differenza dei server web, i database ACID non si espandono facilmente utilizzando hardware parallelo. Se il tuo prodotto non avrà mai successo, questo non è un problema.

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

Come ha detto Javiar, tuttavia, l'utilizzo di un approccio REST come API del database per il tuo prodotto non è davvero sensato. Il vantaggio di un'interfaccia REST è che altre persone penseranno a diversi modi di utilizzare e interrogare la tua interfaccia REST. Tuttavia, si tratta di risorse logiche per le poste pubbliche e non di risorse di record di tabella di basso livello. Il pensiero di rendere disponibili query di dati di così basso livello sull'API HTTP sembra un incubo di sicurezza.


+1, per aver corrotto il problema di compatibilità del browser. Inoltre, la scrittura di codice aziendale in JavaScript richiede un'abilità aggiuntiva e non consente di utilizzare metodi nelle classi aziendali.
NoChance,

2

Mentre ci sono molte scuole di pensiero su questo, e certamente nessun modo può essere definito "il modo giusto" universalmente, mentre tutti gli altri sono "il modo sbagliato" universalmente, ci sono una serie di ragioni per isolare la logica aziendale sul lato server e accedere a tali oggetti e servizi tramite un servizio RESTful.

La risposta breve è che riguarda principalmente la gestione del rischio e il monitoraggio e il miglioramento delle prestazioni.

In dettaglio:

Il motivo principale numero 1 è la sicurezza. I clienti non devono mai avere la certezza di inviare al server qualcosa di diverso dall'immondizia e, mantenendo gli aspetti di sicurezza sul lato server, isolano il potenziale rischio che un utente non autorizzato danneggi il sistema. Ricorda, Javascript è completamente lato client e banalmente modificabile, quindi NON PUOI FIDARTI DELL'USCITA.

Il motivo 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 con Javascript. Isolando la logica di business dalla logica di presentazione, si evita di superare queste preoccupazioni, poiché il javascript non sarà autorizzato ad accedere alle risorse oltre i suoi livelli di autorizzazione e riceveranno errori, la cui gestione è nell'ambito del programmatore di script. Allo stesso modo, il ragazzo 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 per server e database. Mantenendo tale logica isolata dagli elementi dell'interfaccia utente, è quindi 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 i back-end del sistema o del database se i processi aziendali vengono eseguiti sul server.

Un corollario qui è che spesso diversi processi aziendali useranno 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, al fine di mantenere gli standard ACID, Business Logic ha davvero bisogno di essere sul server. Ricordo di aver gestito un prodotto di fatturazione eseguito nel browser Web, con solo una connessione al database al server. Se la fatturazione giornaliera (che potrebbe richiedere un'ora o più in una buona giornata!) Fosse interrotta, ad esempio, in caso di chiusura o arresto anomalo del browser, potrebbero essere necessarie diverse ore per risolvere il disordine che ha creato sul database, che è stato lasciato in uno stato incoerente. Ricorda, ciò implicava anche carte di credito, quindi anche i record di fatturazione dovevano essere controllati con il processore!

La logica aziendale lato server è per lo più banale per garantire gli aggiornamenti ACID, in quanto esistono framework per qualsiasi lingua per mantenere le transazioni, a livello di applicazione o di database. Se lo stai facendo tramite più aggiornamenti da un client Web ... a un certo punto otterrai uno stato incoerente e probabilmente influenzerà la tua applicazione.

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


+1 per aver raccolto molti buoni punti. Il sistema di fatturazione che hai usato come esempio ha il design più strano di cui abbia mai sentito parlare.
NoChance,

Aveva anche il nome più strano di cui abbia mai sentito parlare, anche se vedo ancora riferimenti ad esso in giro. Si chiamava HURLnet ISP Admin ed era piuttosto la creatura da mantenere. Avevamo una licenza completa per il codice sorgente e l'ho utilizzata ampiamente dopo che hanno smesso di supportarla.
SplinterReality,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.