DLL o servizio web per funzioni comuni?

Question

DLL o servizio web per funzioni comuni?

#1 da (6 voti)
#2 da (5 voti)

1

Abbiamo una varietà di funzioni di base (utilità data, invio e-mail, calcoli matematici interni, ecc.) che sono attualmente in un vecchio progetto VB.NET.

Stiamo andando verso C # e mi chiedo se dovremmo scrivere una nuova libreria che le nostre applicazioni possano fare riferimento come DLL o dovremmo creare un servizio web che le nostre applicazioni possano chiamare per fare queste cose?

Il mio attuale pensiero è per le funzioni di base che restituiscono oggetti semplici che possiamo creare un servizio web.

Modifica: il dibattito principale per noi è che se usiamo una DLL che distribuiamo con varie app dobbiamo ridistribuire la DLL a tutte loro se la aggiorniamo in futuro. Con un servizio web, dato che tutte le applicazioni colpiscono un endpoint, lo aggiorniamo.

design c# web-services vb.net wcf

posta Shaw Levin 22.05.2015 - 21:44

fonte

2 risposte

6

Avere un livello aziendale separato ha bisogno di giustificazione perché richiede molto più lavoro e costa di più in termini di prestazioni (si veda: MS-Business Layer ). Secondo una definizione di Servizi Web , in genere non è richiesto un servizio Web a meno che non si stia comunicando tra diversi livelli fisici. Di conseguenza, una DLL può adattarsi meglio a ciò che descrivi. È comune utilizzare i servizi Web per comunicare tra sistemi per l'accesso a database / file. La differenza tra un livello e un livello è importante (vedi Tiers vs. Layers ).

risposta data 22.05.2015 - 22:03

fonte

Leggi altre domande sui tag design c# web-services vb.net wcf

Quali svantaggi ci sono per l'ambito basato sulle condizioni? Come impostare un avvio agile senza il cliente? [duplicare]

score 5 · Accepted Answer

Se l'intero stack è .net, non c'è molto valore nella creazione di servizi web. Basta fare riferimento alle DLL nei componenti .net che ne hanno bisogno, sarà più veloce in quanto non ci sono serializzazioni o hop di rete aggiuntivi.

Tuttavia, per scopi cross-platform, i servizi web sono la strada da percorrere. Quindi puoi avere un client .net (app ASP MVC), client java, client mobile nativo, ecc. Che utilizzano tutte le funzionalità fornite dal tuo servizio .net.

Questo aggiunge un enorme valore quando non sai quali client useranno le tue funzionalità o se la tua organizzazione ha diversi stack tecnologici. Tuttavia, l'aggiunta di servizi Web aggiunge un sovraccarico all'architettura per quanto riguarda la rete e la serializzazione dei messaggi. I servizi Web sono più flessibili / futuri / futuri in modo da poterli scambiare o utilizzare più front-end per lo stesso servizio.