Quali sono i vantaggi e gli svantaggi dell'utilizzo dei servizi rispetto ai componenti?

Question

Negli ultimi mesi sto lavorando a progetti negli ultimi framework di dot net.

Ritengo che nelle ultime versioni di net dot i "servizi" siano incoraggiati rispetto ai componenti. È corretto?

Ho visto in luce argentata (sono un principiante in luce argentata) tutte le operazioni del livello DB sono esposte come servizi. Non so adesso sono disponibili anche i programmi componenti?

Quali sono i vantaggi? Che dire delle prestazioni se tutti i livelli sono esposti come servizi anziché DLL?

Si prega con un po 'di luce su questo argomento che dovrei iniziare a capire correttamente questo concetto?

Grazie

SC

Answer 1

E 'davvero tutto a che fare con una Service Oriented Architecture - qualcosa che è stato comune per un po' ed è molto popolare.

L'idea è che operazioni distinte sono separate l'una dall'altra in modo che possano essere riutilizzate e modificate senza ricompilare le app che la utilizzano. Piuttosto che un pezzo di codice in una DLL che viene modificato e copiato ovunque, è possibile implementare un servizio che rappresenta un singolo punto di accesso per un particolare pezzo di elaborazione o fonte di informazioni.

Supponiamo che tu abbia un componente di convalida della carta di credito. Puoi scrivere questo codice e compilarlo in una DLL e iniziare a includerlo in tutte le tue applicazioni. Niente di male in questo, a meno che non si noti un bug o le regole per la modifica della validazione CC. O forse vuoi aggiornarlo per controllarlo contro una lista nera. Non puoi fare nessuna di quelle cose senza dover ricompilare le app che la usano.

Se la convalida della carta di credito viene tuttavia esposta come servizio, è possibile apportare le modifiche e distribuire in un'unica posizione. A condizione che la firma sia la stessa (stessi parametri e risposta), le applicazioni non devono nemmeno sapere che è stata cambiata.

Un altro vantaggio dell'utilizzo di servizi su componenti è che i servizi possono essere ospitati ovunque. Possono essere sul server locale o dall'altra parte del mondo.

Detto questo, come tutto ciò che si dovrebbe decidere l'architettura caso per caso. Mentre la convalida della carta di credito era un buon esempio di quando un servizio è utile, fornire un servizio per il rendering dei controlli HTML non ha molto senso.

Answer 2

Qualcos'altro da considerare - solo perché la funzionalità è esposta come un "servizio" non significa che debba essere ospitata da qualche parte o esposta come servizio web.

Si potrebbe facilmente accedere a un servizio direttamente, in memoria.

L'esposizione di funzionalità correlate come servizio riguarda più l'interazione tra i vari componenti dell'applicazione. Non dice nulla su come distribuisci/accedi a questi pezzi.

Answer 3

La compatibilità con "linguaggio incrociato" è un altro vantaggio. È possibile scrivere un servizio in C# .net a cui si può accedere anche da Java. Quindi il riutilizzo va oltre l'utilizzo del linguaggio di programmazione.

Quali sono i vantaggi?Che dire della prestazione se tutti i livelli sono esposti come servizi anziché DLL?

Farei attenzione a questo punto qui. Cosa intendi per "tutti gli strati"? Livelli applicativi come Business e Data Access Layer ?? Dubito che ciò possa essere utile (ovviamente dipende dal tuo contesto) ma solitamente un servizio è qualcosa che può essere riutilizzato in molti contesti diversi. Un esempio potrebbe essere un servizio per la convalida del codice fiscale. Chiameresti questo servizio dal livello aziendale della tua applicazione. Non riesco a immaginare un caso in cui esporrai il livello aziendale come servizio separato e il livello di accesso ai dati come un altro separato. Di solito sono abbastanza specifici per la tua applicazione che stai sviluppando. Ciò che potrebbe essere è che tu abbia un'applicazione che è ad esempio accessibile attraverso il web (come applicazione web) e c'è un altro punto di accesso attraverso un servizio web che altre app possono usare (una sorta di API). Ciò avrebbe senso, ma non esponete direttamente il vostro livello aziendale, ma piuttosto create una sorta di "gateway" che è il vostro webservice (una facciata leggera che delega alle vostre classi di logica aziendale).