API REST vs direttamente chiamate DB nell'applicazione desktop

Quando si tratta di applicazioni di grandi dimensioni con un enorme database contenente milioni di record, ci si rende presto conto che semplici selezioni, aggiornamenti, inserimenti ed eliminazioni semplicemente non sono sufficienti.

Quindi inizi a pensare in un modo diverso. Si creano procedure e trigger per occuparsi di cose più complicate direttamente nel database e questo non è molto buono. I database offrono grandi prestazioni durante l'esecuzione di operazioni CRUD. Procedure lunghe? Non così tanto.

Il problema con le procedure

Ora immagina di passare a un database che non supporta il concetto di procedure? Che cosa hai intenzione di fare? Sei costretto a spostare le procedure sul tuo codice base, dove puoi essere abbastanza sicuro che una volta programmato, diciamo Java, rimarrà sempre lì, indipendentemente dal motore di database che scegli.

Per non parlare, le tue procedure sono di solito parte della tua logica aziendale e non è una buona idea avere la tua logica aziendale divisa tra la base di codice e il database.

Idealmente, dovresti sempre avere un mediatore tra il database e il cliente che implementa le proprie regole aziendali. Fornire accesso diretto al database non è una buona idea, perché quando lo fai, quello con accesso ha accesso diretto alle tabelle e può fare praticamente qualsiasi cosa con i dati che ci sono.

Svantaggi

• Ci vuole più tempo per svilupparsi: Naturalmente, stai creando un nuovo sistema, che richiederà più tempo del semplice dare al client una stringa di connessione al database e lasciargli scrivere le query.
• Più complesso: complessità di un sistema > complessità di una query del database.
• Il server fa più lavoro: Non necessariamente. Con una buona progettazione, il caching, ... puoi spostare il carico dal server del database a quello del mediatore.
• Più lento: In termini di sviluppo? Sì. In termini di velocità durante il recupero dei dati? No. Puoi ottimizzare il tuo mediatore usando cache (come - popolare a partire da gennaio 2016 - Redis, Elasticsearch) e renderlo effettivamente più veloce di una semplice query di database.

vantaggi

• La migrazione ad altre piattaforme è più semplice: migrazione verso un nuovo motore di database? Decisamente. Migrare l'intero mediatore in una nuova lingua? Non proprio.
• La Business Logic è necessaria anche quando si chiama direttamente il database. Non ci vorrà molto più tempo per sviluppare: come spiegato in precedenza, il problema delle procedure.
• Sicurezza: con una corretta autorizzazione con mediatore è sicuramente molto più sicuro di un accesso diretto all'utente al database, perché lo limiti ai punti finali che eseguono solo le query che desideri.
• Manutenibilità: uno dei migliori vantaggi di avere un mediatore. Se c'è un bug in un'API che i client chiamano, lo correggi, spinga la correzione al tuo repository VCS, costruisci il tuo mediatore dalla versione curres di VCS che contiene la correzione e tutti i tuoi clienti stanno improvvisamente usando la correzione, senza che loro debbano scarica un aggiornamento. Questo è semplicemente impossibile da fare, se le query sono memorizzate direttamente nelle applicazioni client. In tal caso, i clienti sono costretti ad aggiornare la loro applicazione.

Ecco la mia opinione in merito: hai la giusta idea di voler usare un webservice, ma potresti aver intenzione di usare la tecnologia sbagliata.

Quando dici REST, presumo che tu stia parlando di Asp.Net WebApi. Questa è la tecnologia sbagliata per le applicazioni intranet. REST & WebApi è fantastico, non fraintendetemi, ma per qualsiasi tipo di applicazione interna, i servizi web WCF sono la strada da percorrere a mio modesto parere. Consentono al client di fare riferimento all'endpoint del servizio proprio come una libreria di classi, il che significa che non stai trattando in XML o JSON nel tuo client desktop. Stai lavorando con classi e amp; oggetti.

Comunque, si. Hai l'idea giusta Se non sono sicuri di aver bisogno di un client basato sul web, allora devi architettare il tuo sistema per aggiungerlo facilmente se decidono di volerlo in seguito. È molto più semplice aggiungere diversi tipi di client quando si dispone di un'architettura orientata ai servizi.

Consideralo in questo modo, sicuramente è un modello comune e potrebbe essere ragionevolmente descritto come best practice.

A seconda della piattaforma, è possibile trovare strumenti che fanno quasi scomparire il problema: Microsoft ha il supporto ODATA per le app connesse che dovrebbe rendere i moduli più semplici immediatamente dopo aver scalato la curva di apprendimento.

Più pragmaticamente: definisce l'API necessaria per il livello dati nell'applicazione desktop e il codice per tale API. Metti tutto l'accesso al database dietro questa API - che in realtà migliora le cose dal punto di vista dello sviluppo dell'applicazione - e quindi la posizione del codice di accesso al database diventa meno significativa (la stessa API potrebbe essere implementata dal codice che parla direttamente al database o per codice che parla indirettamente al database tramite un endpoint di riposo). Se inizi con un'implementazione diretta, la versione REST sarà sostanzialmente un wrapper attorno alla stessa API, quindi non sarai penalizzato troppo male ...

Probabilmente non è così semplice come mi piacerebbe farlo - ma è un buon modello, ti dà la flessibilità di cui potresti avere bisogno senza andare molto indietro nel YAGNI percorso.