Quanto è essenziale creare un livello di servizio?

68

Ho iniziato a creare un'app in 3 livelli (DAL, BL, UI) [gestisce principalmente CRM, alcuni rapporti sulle vendite e inventario].

Un collega mi ha detto che devo passare al modello del livello di servizio, che gli sviluppatori sono arrivati al modello di servizio dalla loro esperienza ed è l'approccio migliore per progettare la maggior parte delle applicazioni. Ha detto che sarebbe molto più semplice mantenere l'applicazione in futuro in quel modo.

Personalmente, ho la sensazione che stia solo rendendo le cose più complesse e non ne vedo molti benefici che lo giustifichino.

Questa app ha un'ulteriore piccola interfaccia utente parziale che utilizza alcune (ma solo poche) funzioni dell'applicazione desktop, quindi mi sono ritrovato a duplicare un po 'di codice (ma non molto). Solo a causa di una duplicazione del codice non la convertivo in un servizio orientato al servizio, ma ha detto che dovrei usarlo comunque perché in generale è un'architettura molto buona, perché i programmatori sono così appassionati dei servizi ??

Ho provato a cercarlo su Google, ma sono ancora confuso e non riesco a decidere cosa fare.

— BornToCode
fonte

58

Il libro di Martin Fowler "Patterns of Enterprise Architecture" afferma:

La domanda più semplice a cui rispondere è probabilmente quando non usarla. Probabilmente non è necessario un livello di servizio se la logica aziendale dell'applicazione avrà solo un tipo di client, ad esempio un'interfaccia utente, e le risposte ai casi d'uso non implicano più risorse transazionali. [...]

Ma non appena si prevede un secondo tipo di client, o una seconda risorsa transazionale nelle risposte ai casi d'uso, è utile progettare dall'inizio in un livello di servizio.

I vantaggi offerti da un livello di servizio sono la definizione di un insieme comune di operazioni dell'applicazione disponibili per client diversi e il coordinamento della risposta in ciascuna operazione. Laddove si abbia un'applicazione che ha più di un tipo di client che consuma la sua logica aziendale e presenta casi d'uso complessi che coinvolgono più risorse transazionali, ha senso includere un livello di servizio con transazioni gestite.

Con CRM, Vendite e Inventario ci saranno molti casi d'uso di tipo CRUD di cui è quasi sempre presente una corrispondenza uno a uno con le operazioni del livello di servizio. Le risposte alla creazione, all'aggiornamento o all'eliminazione di un oggetto di dominio devono essere coordinate e gestite atomicamente dalle operazioni del livello di servizio.

Un altro vantaggio di avere un livello di servizio è che può essere progettato per l'invocazione locale o remota, o entrambi - e ti dà la flessibilità di farlo. Il modello pone le basi per l'implementazione incapsulata della logica aziendale di un'applicazione e l'invocazione di tale logica da parte di vari clienti in modo coerente. Ciò significa che puoi anche ridurre / rimuovere la duplicazione del codice, poiché i tuoi clienti condividono gli stessi servizi comuni. Puoi potenzialmente ridurre anche i costi di manutenzione, poiché quando la tua logica aziendale cambia, (in genere) devi solo cambiare il servizio e non ciascuno dei clienti.

In sintesi, è utile utilizzare un livello di servizio - di più, quindi credo che nel tuo esempio tu abbia fornito come sembra che tu abbia più clienti di logica aziendale.

— Deco
fonte

2

È interessante notare che Martin Fowler sostiene la stessa interfaccia per l'invocazione locale e remota, sostenendo che l'enorme differenza di prestazioni nell'invocazione remota impone un'interfaccia più approssimativa.

— psr

Non ho capito bene il tuo paragrafo

With CRM, Sales and Inventory there will be a lot of CRUD-type use cases of which there is almost always a one-to-one correspondence with Service Layer operations

- se si tratta di più interfacce utente, quindi come può entrare CRUD qui? E se non avessi bisogno di più UI anche se il CRUD si adatta bene ai servizi, non avrei comunque creato un livello di servizio, se avessi capito bene, e spero davvero di averlo fatto perché preferisco mantenere le cose semplici (il livello di servizio è un confusione alla mia opinione inesperta)

— BornToCode

4

In quei casi è raro che ci sia un solo client che può trarne vantaggio. Se hai solo un'interfaccia utente, posso pensare a due motivi per cui potresti volere ancora il livello di servizio: sicurezza e riusabilità. Una tipica configurazione aziendale avrebbe l'app UI disponibile per i client esterni e il tuo livello di servizio disponibile solo nella rete. Quindi il web server delega il lavoro a una porzione bloccata della rete. Nell'esempio delle vendite potresti riutilizzare se prendi le vendite dal tuo sito web e ti espandi su eBay o Amazon. Ora hai un'interfaccia utente, ma più client.

— Phil Patterson,

5

Solo per aggiungere al commento di @PhilPatterson. Più client non devono solo essere basati sull'interfaccia utente. Pensa ai servizi web o alle biblioteche: possono anche essere client. L'interfaccia utente del front-end potrebbe utilizzare il livello di servizio, nonché i servizi software impacchettati e consentire a qualcun altro di utilizzare.

— Deco,

puoi fornire un esempio di un livello di servizio?

— user962206,

34

Aggiunta di un livello di servizio perché hai valutato l'idea e concluso che è l'approccio migliore: buono

Aggiungere un livello di servizio perché è quello che fanno tutti i ragazzi fighi: cattivo

Se il tuo intestino dice che non ne hai bisogno, non crearne uno.

Uno degli sviluppi più deludenti nel mondo della programmazione negli ultimi 10 anni o giù di lì è che è diventato fastidiosamente orientato alla "moda", con le persone che seguono tendenze e vagoni come se fossero le scarpe di questa stagione. Non cadere in quella trappola. Perché la prossima stagione "tutti" ti diranno che avresti dovuto progettarlo in un altro modo.

Non c'è niente di sbagliato o giusto in un livello di servizio: è un approccio particolare la cui idoneità dovrebbe essere valutata in base ai suoi meriti tecnici per il progetto in questione. Non sentirti costretto a sostituire le opinioni degli altri con il tuo giudizio.

— GrandmasterB
fonte

27

Questo non affronta affatto l'argomento, ma fa solo una dichiarazione generale sulle pratiche di sviluppo che, dopo aver sostituito alcune parole, potrebbero applicarsi a qualsiasi domanda su questo sito. Dalla lettura di questa risposta, non sono nemmeno convinto che si sa esattamente quello che un livello di servizio è .

— Aaronaught,

12

Certamente può essere applicato ad altre domande ... non lo rende meno vero. Il fatto è che né tu né io abbiamo alcuno vicino al contesto necessario per affermare ciò di cui ha bisogno nel suo progetto, quindi dirgli di sì che ne ha bisogno, o no che non lo fa, è solo un'ipotesi semplice e poco professionale. Ciò di cui l'OP ha bisogno qui è un po 'di supporto morale per prendere le decisioni che sa essere quelle giuste.

— GrandmasterB,

5

@Aaronaught Indipendentemente dalla correttezza della risposta, sta essenzialmente rispondendo alla domanda principale, "Quanto è essenziale un livello di servizio?". Afferma che non è affatto essenziale e che forse è solo una moda passeggera. Se non sei d'accordo con la risposta, ti preghiamo di votare.

— maple_shaft

2

@GrandmasterB Direi che le mode sono buone nello sviluppo del software. La maggior parte degli sviluppatori è troppo fresca o incompetente per prendere decisioni di progettazione e architettura ben informate. Ci aspettiamo comunque che presentino una parvenza di software funzionante, quindi saltare su un carrozzone ed essere coerenti con una scelta di design scadente è di gran lunga preferibile e più mantenibile rispetto al modo in cui sono state fatte anni fa dove avremmo codificato il cowboy in tutto ciò che non ho capito o apprezzato.

— maple_shaft

10

@maple_shaft Giusto per chiarire, non sto dicendo che i livelli di servizio sono una mania. Sto dicendo, in base al modo in cui la domanda è stata posta, che sembra che ci sia / moda / carrozzone bizzarro comportamento da parte dei suoi colleghi per spingerlo ad utilizzare un'architettura che pretende molto pensare è warrented nel suo progetto. Spiego chiaramente nella mia risposta che considero i Livelli di servizio (o qualsiasi altro concetto) proprio come questi: concetti neutrali la cui idoneità dovrebbe essere valutata in base al loro merito per i singoli progetti. Non dovrebbero essere applicati / usati quando il proprio giudizio dice che non sono necessari.

— GrandmasterB,

22

Ci sono molti fattori che vanno nella decisione di creare un livello di servizio. Ho creato livelli di servizio in passato per i seguenti motivi.

Codice che deve essere riutilizzato da più client.
Librerie di terze parti per le quali disponiamo di licenze limitate.
Terze parti che necessitano di un punto di integrazione nel nostro sistema.
Centralizzazione della logica aziendale duplicata.

Caso 1: stai creando funzionalità di base che devono essere utilizzate da una miriade di client diversi. Il livello di servizio integra funzionalità per diversi client per sfruttare immediatamente la funzionalità fornita.

Caso 2: normalmente si ospita il codice nello spazio app ma si utilizza una libreria di terze parti per la quale si dispone di licenze limitate. In questo caso hai una risorsa che vorresti usare ovunque, ma solo un numero limitato di essi. Se lo si ospita dietro un servizio, l'intera organizzazione può utilizzarlo dalle proprie applicazioni senza dover acquistare una licenza per ogni singolo hosting.

Caso 3: stai creando funzionalità per farti comunicare da terze parti. Nel tuo esempio potresti impostare un endpoint di inventario per consentire ai fornitori di inviarti messaggi sulle spedizioni di prodotti in arrivo.

Caso 4: hai analizzato il tuo codice a livello aziendale e hai scoperto che team separati hanno creato la stessa cosa (implementata in modo leggermente diverso). Con un livello di servizio puoi scegliere i migliori approcci e ora puoi implementare lo stesso processo in tutti i team facendoli chiamare nel servizio. Un altro vantaggio della centralizzazione della logica è quando vengono rilevati dei bug. Ora puoi distribuire la correzione una volta e tutti i client godono il vantaggio allo stesso tempo.

Detto questo, ci sono potenziali negativi per un livello di servizio.

Aggiunge la complessità del sistema. Dove prima avevi una sola applicazione per il debug ora ne hai due. I problemi di produzione richiedono il controllo delle impostazioni dell'app client, delle impostazioni dell'app di servizio o dei problemi di comunicazione tra le app client e server configurate correttamente. Questo può essere complicato se non l'hai mai fatto prima.
Un punto di fallimento. Se si verifica un'interruzione del servizio, tutti i client sono interessati. Quando il codice non viene distribuito in questo modo, il rischio può essere inferiore (anche se ci sono modi per mitigarlo).
Il controllo delle versioni può essere più difficile da fare. Quando si dispone di un'app che utilizza un servizio che distribuisce le modifiche all'interfaccia, è possibile eseguire contemporaneamente le due operazioni. Quando hai più client ora devi gestire chi è su V1, chi è su V2 e coordinare la rimozione di V1 (una volta che sai che tutti hanno aggiornato a V2).

Il punto principale è che non è sempre una schiacciata per orientare il servizio di sistema. Nella mia esperienza, di solito è una buona idea (tendo a strutturare le applicazioni in questo modo), ma non è una decisione automatica. Alla fine della giornata devi valutare i pro ei contro e prendere la decisione giusta per la tua situazione.

— Phil Patterson
fonte

2

+1 Grazie per la risposta informativa. Avevo davvero dei dubbi sul tempo per accettare la tua risposta o la risposta di Deco. Alla fine, poiché non sono troppo esperto, ho deciso di scegliere la risposta che ottiene la maggior parte dei voti. Sento ancora che la tua risposta meriterebbe più voti. In ogni caso, apprezzo davvero che tu abbia condiviso le tue conoscenze ed esperienze. Grazie!

— BornToCode

1

Prego! Il punto principale da togliere a entrambe le risposte è che si tratta (principalmente) di risolvere problemi di manutenzione con avere più clienti che devono fare la stessa cosa. Maggiore è il numero di clienti che utilizzano il servizio, maggiore sarà il guadagno di manutenzione per te.

— Phil Patterson,

1

C'è anche sicurezza: i livelli di servizio possono fornire un altro muro per gli hacker da violare per raggiungere il tesoro nel DB. La mancanza di livelli di servizio è forse il motivo per cui così tanti siti Web ottengono enormi violazioni, con un servizio nel mezzo, gli hacker otterrebbero significativamente meno dati prima che vengano rilevati.

— gbjbaanb,

6

La maggior parte dei livelli di servizio che ho visto sono un casino completo. I servizi tendono ad avere molti metodi diversi, 1500 LOC non sono rari. I diversi metodi non hanno nulla in comune, ma condividono il codice. Ciò si traduce in elevato accoppiamento , bassa coesione . Inoltre, viola OCP , perché ogni volta che è necessaria una nuova operazione, è necessario modificare il codice anziché estendere la base di codice. Un livello di servizio ben costruito è teoricamente possibile, ma non l'ho mai visto in pratica.

CQRS risolve questi problemi e ti impedisce di creare uno di quei livelli di servizio procedurali.

— Jeroen
fonte

2

Ben costruito da chi standard però? Certamente per gli standard OO un'interfaccia del livello di servizio è un completo disastro di un pasticcio. Da un punto di vista funzionale o procedurale, incoraggia un bellissimo approccio progettuale a più livelli. Penso che il più grande problema che le persone hanno con i livelli di servizio sia che incoraggiano un'applicazione basata su transazioni senza stato e scoraggiano un approccio orientato agli oggetti. Riesco a capire entrambe le parti dell'argomento.

— maple_shaft

6

L'aggiunta di un'interfaccia (un livello di servizio è un tipo di interfaccia) richiede tempo. Uno buono richiede molto tempo per progettare e testare. È molto importante farlo subito al primo tentativo perché cambiarlo in seguito rompe tutti i client. Inoltre, considera che probabilmente non saprai cosa deve essere presente in quell'interfaccia fino a quando non avrai un secondo client con esigenze leggermente diverse. Mantenere un servizio è un progetto senza fine in sé.

Nella maggior parte delle organizzazioni, se vai dal tuo sponsor aziendale e chiedi loro "Vuoi che altri dipartimenti traggano vantaggio dal (riutilizzo) questo sistema che stiamo sviluppando con il tuo budget?" rideranno di te. Fallo funzionare prima per il tuo sponsor aziendale, quindi inizia a scherzare con il riutilizzo di quel codice (all'ora del tuo dipartimento).

Se sai, per certo, che la funzionalità che stai scrivendo oggi verrà riutilizzata da più client di servizio diversi, quindi considera di progettare un livello di servizio dal primo giorno. Se non sei sicuro, o ci sono già molte incognite nel progetto, fai prima qualcosa di semplice e separalo in servizio e client in seguito se hai tempo e budget. È molto più semplice ottenere l'interfaccia di servizio al primo tentativo quando si inizia con un sistema funzionante.

PS Se lavori in Java, Joshua Bloch ha molti consigli di interfaccia fantastici in tutto il suo libro, Effective Java.

— GlenPeterson
fonte

Un'ottima risposta senza teorie sterili.

— danilo,

2

Sono d'accordo con te. Non è necessario includere un ulteriore livello se si utilizza un'unica interfaccia utente.

DAL, BL e UI / Controller sono una buona combinazione per progettare un'applicazione. Se stai pianificando di utilizzare un'unica interfaccia utente, non è necessario preparare un livello aggiuntivo. Includere 1 ulteriore livello nell'applicazione aumenta solo gli sforzi / i tempi di sviluppo.

Un altro schenerio è usare più UI nella tua applicazione, è bene avere un livello di servizio per gestire le UI in questo caso.

Stack Overflow: discussione sul modello del livello di servizio

— Satish Pandey
fonte

Quindi suggerisci che su ogni complessa applicazione che si sviluppa dovrebbe usare un livello di servizio e non solo accontentarsi di livelli DAL, BL, UI?

— BornToCode

In caso di più UI dobbiamo includere un livello di servizio. Nel tuo caso, non penso che sia necessario preparare un nuovo livello. Aumenta solo la complessità dell'applicazione.

— Satish Pandey,

0

Vorrei contestare che il tuo BL è il tuo livello di servizio. Un luogo centrale in cui si trova la tua logica aziendale. Questa dovrebbe essere una DLL che può essere utilizzata da tutto ciò che necessita di tale logica. Quindi puoi aggiungere un livello API Web se l'app avrà interfacce utente diverse.

— user441521
fonte