Data Access Layer come servizio Web - È una buona idea?

Question

Ho svolto ricerche per un po 'e ho effettivamente creato un prototipo di servizio Web ASP.NET come DAL per alcuni siti Web ASP.NET 2.0. Vorrei semplicemente chiedere alcuni consigli/approfondimenti da parte di sviluppatori più esperti là fuori che avevano distribuito con successo DAL come servizio web. Quali sono gli svantaggi/i rischi legati alla distribuzione di DAL come servizio Web? Qual è il modo migliore per proteggere o autenticare il consumo di questo servizio web? WCF è fuori questione, codificherò in VS 2005.

Grazie.

Answer 1

Penso che il più grande svantaggio di tale approccio sia l'overhead aggiuntivo di chiamare il servizio web. Se hai bisogno di frequenti richieste/aggiornamenti a DAL, questo può diventare piuttosto lento.

La mia opinione è che tale approccio è una specie di overengineering, a meno che non si abbia realmente bisogno di separare fisicamente il DAL per diversi consumatori e si necessita di qualche ulteriore convalida/elaborazione in DAL (che è comunque un errore).

La protezione può essere piuttosto semplice. È possibile utilizzare SSL insieme all'autenticazione di IIS per l'interfaccia del servizio pubblico.

Quindi, questi sono i miei $ 0,03

Answer 2

L'unica vera sfida che io abbia mai affrontato con l'esposizione di dati su un servizio web-based è stato ASMX sognare tutti i metodi necessari per ottenere i dati in modo efficiente. A volte è difficile avere la disciplina per onorare il livello tra l'applicazione e il database.

Se si sta eseguendo la distribuzione in un ambiente Intranet con AD, l'autenticazione integrata di Windows è un modo eccellente per controllare chi può e non può interagire con un servizio. È utile raggruppare le classi di servizio in base ai ruoli dei consumatori, in modo che permissions can be controlled declaratively in the Web.config. Tendo a mantenere i metodi di lettura in una classe di servizio diversa rispetto all'inserimento di metodi di aggiornamento e cancellazione

Evitare le chiamate di servizio chatty. Naturalmente, è bene evitare le chiamate al database di chiacchiere in un sistema a due livelli, ma si pagherà il piper per le chiamate chatty quando si aumenta il numero di livelli. Scegli di inviare oggetti più grandi. Ad esempio, se si dispone di una tabella con poche ricerche, l'invio di un oggetto attraverso il filo con valori cercati in precedenza spesso vi salverà una seconda o terza chiamata e non dovrebbe causare un onere eccessivo sul sistema.

Spero che queste idee aiutino.

Answer 3

Raccomanderei contro questo finché non è possibile passare a WCF. Altrimenti, passerai tutti i tuoi dati avanti e indietro in XML basato su testo su HTTP, il che rallenterà notevolmente le cose. Avrai anche pochissima scelta sulla sicurezza, essendo limitato a SSL per la crittografia.

WCF consente di inviare dati binari su TCP/IP, named pipe o code di messaggi e consente una grande flessibilità in termini di sicurezza. sguardo

Answer 4

Let a questo dal punto di vista l'evoluzione dei progetti di sviluppo software "Enterprise":

1. Inizia con una molto semplice, ben organizzato, e forse nuova applicazione con problemi di manutenzione poco (se si' sono fortunato). I programmatori potrebbero essere recenti, ma il sistema è giovane o pulito abbastanza da essere molto agile e rispondere rapidamente alle richieste di modifica. La maggior parte del codice di database è in stored procedure. Non è coinvolto DBA.
2. L'applicazione cresce e vi è la necessità che più programmatori lavorino nell'app contemporaneamente.I nuovi laureati scoprono il controllo del codice sorgente per aiutarli a condividere il codice tra più programmatori e ad allontanarsi dalle stored procedure a favore della progettazione n-Tier o di un ORM per semplificare la versione del codice del database. Funziona bene fino a quando ogni singola app è abbastanza isolata. Un DBA può ora iniziare ad aiutare a regolare le query.
3. Questo alla fine si evolve in un sistema di app interconnesse che è cresciuto organicamente piuttosto che dal design. Le richieste di modifica diventano difficili, poiché i cambiamenti in un'area hanno effetti sottili negli altri. Per risolvere questo problema di più app che parlano allo stesso database e che hanno bisogno di condividere una logica di business comune e complessa, i programmatori si rivolgono a un'architettura orientata ai servizi (servizi web). Vecchi dati e livelli aziendali vengono analizzati, combinati e rielaborati in un insieme comune di servizi Web. La maggior parte dei programmatori ora non sa più nemmeno come connettersi al proprio database: solo chi lavora sui servizi di base è autorizzato a farlo, e anche loro devono lasciare qualsiasi sql reale al DBA. Se il test dell'unità non è già in uso, viene ora scoperto come parte di un sistema di integrazione continua.
4. Il sistema continua a crescere, ma l'azienda cresce ancora più velocemente. Ogni cosa funziona; la qualità è buona e le prestazioni non sono eccezionali, ma comunque accettabili. Il problema è che i tassi di cambiamento sono troppo lenti. Gli strati di processo tra i programmatori e il codice impediscono loro di tenere il passo con il business in un modo economico. Qualcuno scopre metodi agili.
5. Torna al passaggio 1.

Per fare di nuovo serietà, ponendolo in questo contesto, vediamo che i servizi Web comprendono davvero sia il livello dati sia il livello aziendale. Lo scopo di un livello di servizio è quello di imporre la condivisione di un insieme comune di regole tra più applicazioni. Lasciare il livello aziendale fuori dal tuo servizio dà ai programmatori la possibilità di scrivere il proprio codice commerciale per ogni applicazione, e questo è davvero controproducente allo scopo di utilizzare i servizi in primo luogo.