Perché uno sviluppatore dovrebbe utilizzare i servizi Web invece di connessioni dirette a un database? [chiuso]

93

Sto cercando un elenco dei "primi dieci" motivi per cui dovremmo connetterci a database remoti tramite il servizio web invece di collegarci direttamente al database. Questo è un dibattito interno in questo momento e io sono un servizio a favore del web, ma sto perdendo la discussione. Ho una conoscenza di base di WCF / servizi web, nessun altro lo sa. Possiamo fare tutto ciò che vogliamo andando avanti, ma dobbiamo restare fedeli a ciò che scegliamo ora.

Ecco cosa ho pensato. Più?

  1. I servizi Web WCF possono, se configurati correttamente, essere più sicuri.
  2. Le modifiche al DB devono essere apportate solo a livello di servizio (file di configurazione o servizio di ricompilazione).
  3. Una volta configurati e ospitati, i servizi Web sono più facili da utilizzare.
wcf  web-services 
— DenaliHardtail
fonte

Risposte:

120

  1. Sicurezza. Non stai concedendo l'accesso al DB a nessuno tranne che all'utente del server web / dell'app.

    Questo è molto importante quando hai tonnellate di utenti. Eviti il ​​problema della manutenzione di utenti / ruoli sul lato DB.

  2. Riduzione del carico DB. Il servizio Web può memorizzare nella cache i dati recuperati dal DB.

  3. Pool di connessione al database (hat / tip @Dogs).

    Un servizio Web può utilizzare un piccolo pool di connessioni DB aperte in modo permanente. Gli aiuti in vari modi:

    • Il pool di connessioni DB è limitato sul lato server del database.

    • aprire una nuova connessione DB è MOLTO costoso (soprattutto per il database server).

  4. Capacità di tolleranza agli errori: il servizio può passare da origini dati primarie a DR senza che i consumatori del servizio implementino i dettagli del failover.

  5. Scalabilità: il servizio può diffondere le richieste tra diverse origini dati parallele senza che i consumatori del servizio implementino i dettagli della selezione delle risorse.

  6. Incapsulamento. È possibile modificare l'implementazione del database sottostante senza influire sugli utenti del servizio.

  7. Arricchimento dei dati (questo include qualsiasi cosa, dalla personalizzazione del client alla localizzazione all'internalizzazione). Fondamentalmente uno qualsiasi di questi potrebbe essere utile, ma ognuno di essi è un carico importante sul database e spesso molto difficile da implementare all'interno di un DB.

  8. Può o non può essere applicabile a te: alcune decisioni sull'architettura non sono facili da usare per DB. Ad esempio, i server Java in esecuzione su Unix hanno un facile accesso a un database, mentre un client Java in esecuzione su un PC Windows non è a conoscenza del database né si desidera che lo sia.

  9. Portabilità. I tuoi clienti potrebbero non essere tutti sulla stessa piattaforma / architettura / lingua. Ricreare un buon livello di accesso ai dati in ognuno di questi è più difficile (poiché deve tener conto di problemi come i failover sopra menzionati / ecc ...) che costruire un livello consumer per un servizio web.

  10. Ottimizzazione delle prestazioni. Supponendo che l'alternativa siano i client che eseguono le proprie query (e non le stored procedure predefinite), puoi essere sicuro al 100% che inizieranno a utilizzare query non ottimali. Inoltre, se il servizio Web limita il set di query consentite, può aiutare in modo significativo l'ottimizzazione del database. Devo aggiungere che questa logica è ugualmente applicabile alle stored procedure, non univoca ai servizi web.

Un buon elenco può essere trovato anche in questa pagina: "Incapsulamento dell'accesso al database: una" pratica "agile"

Giusto per essere chiari: alcuni di questi problemi potrebbero non essere applicabili a TUTTE le situazioni. Ad alcune persone non interessa la portabilità. Alcune persone non devono preoccuparsi della sicurezza del DB. Alcune persone non devono preoccuparsi della scalabilità del database.

— DVK
fonte
26
Scusa, non sono d'accordo. 1. Quindi concedi l'accesso al database a un gruppo invece che a un singolo principale - nessuna differenza. 2. Qualsiasi app può memorizzare nella cache i dati. In ogni caso, il tipo di dati che possono essere memorizzati nella cache tra più utenti sarà generalmente dati a basso volume. 3. FT dovrebbe in ogni caso essere gestito dal database. 4. Questa non è una funzionalità predefinita e deve essere programmata. 5. Il tuo livello di accesso ai dati dovrebbe fare l'incapsulamento. 6. Stessa cosa. 7. Davvero? JDBC non viene eseguito in un client? 8. Buon punto, quando è importante, il che è raro. 9. query vs. SP non faceva parte della domanda.
— John Saunders
7
1. Prova a gestirlo su 5000 utenti con centinaia di ruoli. Non scala più così bene. 2. Dipende interamente da un'app. Il nostro caso attuale ha un'istanza di memorizzazione nella cache dei risultati di una query che, nel caso ottimizzato per uber, richiede 20 minuti per essere eseguita e che dobbiamo eseguire centinaia di volte al giorno almeno da app diverse. 3. FT viene gestito su una serie di livelli. Cosa intendi per "dovrebbe essere gestito da un database"?
— DVK
4
4. Ovviamente deve essere programmato. Ma può essere programmato nel servizio una volta o in un trilione di app client su varie piattaforme con funzionalità diverse. C'è una grande differenza. Non importa i problemi di gestione della configurazione per il bilanciamento del carico. 5. Stesso ragionamento. Non è necessario reimplementare DAL. In effetti, puoi pensare al servizio Web come a un DAL portatile per rilassare la mente. 7. Non vogliamo che tutti i client aprano connessioni DB. È una cosa così grande da chiedere? Ancora una volta, stai dimenticando i punti 1-5.
— DVK
2
8.> 1 architettura client si verifica MOLTO spesso. In realtà non ho mai lavorato a un progetto senza una situazione del genere nella mia vita, ma sono concentrato nel mondo finanziario. 9. Non lo era. Fondamentalmente stavo facendo l'avvocato del diavolo.
— DVK
2
Mi piace questa risposta, ma penso che tu abbia saltato uno dei punti più importanti: il pool di connessioni. Se hai 1.000.000 di client, avrai 1.000.000 di connessioni aperte o milioni di connessioni costantemente aperte e chiuse. L'intuizione di base sull'organizzazione del computer ci dice che un pool ben sintonizzato di un paio di centinaia di connessioni di lunga durata è astronomicamente più efficiente di avere un milione di connessioni di lunga durata o milioni di connessioni di breve durata. L'HikariCP documenta un ottimo lavoro nell'elaborare questa idea: github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
— Dogs
15

A mio parere, non dovresti esporre automaticamente il tuo database come servizio web. Se si scopre che è necessario un servizio per esporre i dati, scriverne uno, ma non tutti gli accessi al database dovrebbero essere effettuati tramite servizi web.

  1. Non c'è motivo per cui una connessione al database non dovrebbe essere sicura
  2. È possibile incapsulare il database in un livello di accesso ai dati (possibilmente Entity Framework)
  3. I servizi Web non sono più facili da utilizzare di un livello di accesso ai dati ben scritto.
— John Saunders
fonte
Perché necessariamente XML? C'è anche molto più leggero per analizzare JSON, CSV per semplici dati flat, ecc ...
— DVK
Non è "senza una buona ragione". Come notato, a seconda delle tue esigenze e desideri per lo sviluppo futuro, potrebbe essere necessario per il tuo progetto.
— Chris Stewart,
Scrivo il mio WS per consumare un DAL. Su quale porta suggeriresti di esporre un DAL?
— samis
@samus non importa.
— John Saunders
"Non c'è motivo per cui una connessione al database non debba essere sicura", beh, è ​​difficile, ad esempio, proteggere la connessione tra un client Windows e un database. Davvero difficile implementare una connessione sicura!
— NoChance
12
  • I servizi Web formano un'API, definendo le interazioni consentite tra i sistemi esterni e i dati dell'applicazione.
  • I servizi Web disaccoppiano il database dalle interazioni esterne e consentono di gestire il livello dati indipendentemente dalle influenze esterne.
  • Consentire l'accesso solo ai servizi Web garantisce che la logica dell'applicazione abbia la possibilità di essere eseguita, proteggendo l'integrità dei dati.
  • I servizi Web consentono di adottare le misure di autenticazione / autorizzazione più appropriate, a differenza di un database che richiede un nome utente e privilegi a livello di password / tabella.
  • I servizi Web offrono l'opportunità di utilizzare il rilevamento e la configurazione automatici dei servizi.
  • Il traffico dei servizi Web può essere crittografato per il transito su reti non protette. Non conosci alcuna soluzione di connessione DB diretta che lo consenta ...?

La maggior parte di questi punti vale per qualsiasi API formale, non specificamente per i servizi Web.

— brabster
fonte
1
Sì, era quello che stavo per dire, se hai una singola applicazione che accede a un database, tutti i tuoi punti sono disponibili anche per le normali API.
— Ignacio Soler Garcia
"I servizi Web formano un'API, definendo le interazioni consentite tra i sistemi esterni e i dati dell'applicazione." Puoi farlo anche con un database.
— Scarpa
"Consentire l'accesso solo ai servizi Web garantisce che la logica dell'applicazione abbia la possibilità di essere eseguita, proteggendo l'integrità dei dati". - Direi che l'integrità dei dati dovrebbe far parte solo del DBMS.
— Scarpa
@Shoe È bello applicare quanta più integrità possibile da parte del DB, ma quando i dati iniziano a popolarsi e ad esporre carenze, come la necessità di una convalida dell'input, è bello applicarlo a livello di applicazione (anche se io per primo preferisco applicare sul lato client, a volte deve essere gestito dal lato server se le regole di convalida dipendono da dati noti solo al server (conservati dall'app client)). È un grosso problema cambiare il set di regole di integrità di un DB, immagino che non sia una questione banale?
— samis
2

Scrivere un servizio web che racchiuda semplicemente le chiamate alle stored procedure sembra essere un approccio fuorviante alla progettazione di un buon DAL. Molto probabilmente, le procedure memorizzate sono codice legacy lasciato da un vecchio sistema client-server, ovvero le regole aziendali sono sepolte negli SP. Se è così, stai davvero cercando di creare una borsa di seta dall'orecchio di una scrofa.

Inoltre, stai aggiungendo un livello di protocollo del messaggio SOAP che aggiunge un calo delle prestazioni alle app web che sono state "costrette" a frequentare questo "maiale". In questo momento sto lavorando a un progetto in cui la nostra nuova app MVC-4 è stata incaricata di utilizzare un DAL di questo tipo. Abbiamo l'onere di dover modificare sia la firma WebMethod che la firma SP ogni volta che arriva una nuova user story che richiede tali modifiche; che per noi è ogni singolo sprint. Inerente a tale approccio passante ci sono due livelli strettamente accoppiati.

— Sevasanakid
fonte
1
L'API Web ha risolto il problema del bloat WCF / SOAP. Ora è come un felino leggero, in forma, agile; proprio quello di cui ha bisogno per servire RESTfully.
— samis
In teoria, non è sbagliato chiamare stored procs utilizzando i servizi web.
— NoChance
2

1) Il mal di testa per la manutenzione del database viene ridotto dagli sviluppatori in modo che possano concentrarsi solo sullo sviluppo.

2) Il servizio Web supporta la comunicazione di diverse piattaforme (sistemi operativi come Windows, iOS, Android, ecc.) In un metodo molto semplice ed efficace. ad esempio, si consideri una situazione in cui l'applicazione Android e l'applicazione iOS vogliono comunicare con un sito Web basato su Java, quindi per la comunicazione di tutte e tre le cose, il servizio Web è la soluzione migliore invece di mantenere tre database diversi.

— Rohan
fonte
1

In generale

  1. Il livello di servizio Web promuove il riutilizzo delle richieste di dati comuni per più applicazioni
  2. Il servizio Web può essere configurato con la gestione delle versioni che devia molti problemi derivanti dallo sviluppo a livello di applicazione. Ad esempio, se sono nuovo in un progetto, quale applicazione esistente devo utilizzare come buon modello per configurare la mia applicazione per utilizzare origini database esistenti.
  3. Il servizio Web si è evoluto per consentire opzioni flessibili per inviare richieste e ottenere risultati di risposta in un formato comune come JSON utilizzando un semplice URI, il che significa che le applicazioni client possono essere sviluppate utilizzando uno standard più comune che incoraggia interfacce uniformi affidabili.

Sto solo iniziando con ASP.NET Web Api e ho intenzione di creare prima i servizi dati.

Recentemente mi sono concentrato sulle applicazioni web .NET MVC con l'uso del framework delle entità.

  1. Se utilizzi già MVC, Web Api utilizza anche MVC con il controller Api, quindi la curva di apprendimento per creare i servizi è abbastanza indolore.

Di recente mi sono trovato in una situazione frustrante con un'app Web MVC che stavo creando originariamente sulla base di procedure archiviate Oracle. La versione originale come Oracle 9 o anche precedente che presentava un altro problema con Visual Studio 2012 che spingeva un approccio di fabbrica di connessioni più moderno con assembly del tempo di caricamento che trovavano i file dll giusti da utilizzare in base alle connessioni di configurazione web e ai nomi TNS.

I tentativi di connessione al database non sono riusciti con messaggi di errore "non più supportati". Per curiosità ho scaricato Oracle 12c e ho effettuato alcune connessioni a livello di applicazione che funzionavano bene con i miei nomi TNS e la dll dell'assembly di carico e sono stato in grado di lavorare con Oracle senza problemi.

Sono stati creati alcuni servizi Web che funzionavano con connessioni alla versione precedente di Oracle. Sono stati costruiti con metodi che sono stati specificamente mappati su tabelle selezionate, tuttavia con mia delusione. Dovrei scrivere il mio.

Mi è stato detto che il gruppo responsabile della manutenzione dei database Oracle avrebbe scritto nuove procedure memorizzate per sostituire quelle più vecchie che stavo utilizzando per astrarre l'interfaccia client e i livelli di logica aziendale.

Quindi il mio primo pensiero è stato che tutte le richieste di dati comuni, come il riempimento di un elenco a discesa o il completamento automatico con dati a livello aziendale, fossero eseguite tramite servizi di dati che chiamerebbero le procedure memorizzate Oracle. Perché ripetere quel processo su ogni applicazione e fare in modo che ogni sviluppatore abbia difficoltà con la configurazione e l'assemblaggio di versione / caricamento, problemi di TNS?

così....

  1. Per più problemi del server di database come l'utilizzo di procedure archiviate Oracle in un'applicazione .NET MVC che di solito potrebbe utilizzare EF per l'utilizzo dei dati di SQL Server, perché non spingere quei mal di testa ai metodi del servizio Web Api in cui tali problemi di configurazione possono essere isolati.
  2. Anche in questo caso l'interfaccia client può essere eseguita utilizzando JavaScript, JQuery e JSON che stai già utilizzando se lo stai facendo utilizzando Web Api per effettuare richieste di dati di SQL Server.

Sono uno sviluppatore / analista di applicazioni e non un amministratore di database, quindi la mia prospettiva è quella dell'esperienza con la frustrazione infinita di dover modificare costantemente le applicazioni quando gli strumenti di database si evolvono.

— Brian Quinn
fonte
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.