Motivazione per un livello di servizio (invece di copiare semplicemente dll)?

7

Sto creando un'applicazione che ha 2 interfacce utente diverse, quindi la sto facendo con un livello di servizio che ho capito è appropriato per tale scenario.

Tuttavia mi sono trovato solo a creare metodi web per ogni singolo metodo che ho nel livello BL, quindi i servizi sono fondamentalmente costruiti con metodi che assomigliano a questo:

return customers_bl.Get_Customer_Prices(customer_id);

Ho capito che un punto principale del livello di servizio è impedire la duplicazione del codice, quindi mi sono chiesto: perché non importare semplicemente BL.DLL (e dal.dll) nell'altra UI e ogni volta che apporti una modifica -Copy le DLL, potrebbe non essere così 'pulito', ma ancora meno fastidio di un altro strato?

{So che c'è qualcosa di sbagliato nel mio approccio, probabilmente mi manca l'importanza del livello di servizio, mi piacerebbe avere più motivazione per creare un altro livello, soprattutto perché come ho scoperto che molte delle mie funzioni BL GIÀ si presenta come:  %codice% che mi ha portato a chiedere: era davvero necessario creare il BL solo perché su più funzioni ho effettivamente LOGIC all'interno del BL?}

quindi sono alla ricerca di più motivazione per creare un livello ONE MORE , sono sicuro che non è solo per rendere più conveniente che non dovrò copiare nuovamente le dll sulle modifiche ?

Lo sto afferrando male? Qualche semplice linea guida su come progettare il livello di servizio (corrispondente a tutte le funzioni del livello BL o no? Un semplice esempio?) Qualsiasi illuminazione sul soggetto?

    
posta BornToCode 24.09.2012 - 16:56
fonte

3 risposte

14

Penso che la parola "servizio" sia stata messa in giro così tanto che oggi il suo significato è molto sovraccarico e confuso.

C'è una grande differenza tra un "livello di servizio" e un "servizio web [livello]".

Un "livello di servizio" è un'astrazione dietro la quale si inserisce la logica aziendale che verrà consumata indipendentemente dall'interfaccia utente. In questo modo il livello dell'interfaccia utente può essere il più semplice possibile (ed è il più semplice possibile aggiungere più interfacce utente in seguito).

Un punto importante da considerare è che il livello di servizio non deve essere un servizio web . Il tuo BL.dll, come lo descrivi, è un livello di servizio. Se entrambe le interfacce utente possono utilizzare BL.dll, è sufficiente importare BL.dll e proseguire da lì. Non è necessario un servizio Web a meno che l'applicazione richieda un servizio Web per altri motivi.

In effetti, non considererei nemmeno un servizio web come un "livello di servizio". È semplicemente un'altra forma di interfaccia utente. Un'interfaccia utente speciale, per essere sicuro; uno progettato per essere consumato da altre applicazioni. Tuttavia, un'interfaccia utente, in particolare nel senso che non dovrebbe esserci alcuna logica aziendale nel livello del servizio Web, oltre all'autenticazione / autorizzazione. Il miglior livello del servizio web fungerà da pass-through al livello di servizio reale sottostante.

In breve , non vedo il motivo per cui dovresti pensare di aggiungere un "livello di servizio web" a meno che l'applicazione ne abbia bisogno (perché i livelli dell'interfaccia utente non possono consumare direttamente la dll del livello di servizio) .

    
risposta data 24.09.2012 - 17:15
fonte
3

Il vantaggio di un servizio di applicazione (non deve essere un servizio Web) su una DLL è che è possibile scaricare l'esecuzione del servizio su una macchina separata (probabilmente un server). Nel caso in cui l'interfaccia utente sia un'app desktop, il computer locale non ha bisogno di avere tanto codice installato né ha bisogno di tanta potenza per far funzionare la tua app.

Un sito Web potrebbe ancora utilizzare questo servizio applicativo.

Come indicato da Andy B, devi determinare quanti utenti devi gestire per giustificare questa spesa.

    
risposta data 24.09.2012 - 19:58
fonte
1

Quanti clienti hai intenzione di supportare? A seconda della piattaforma sottostante su cui si sviluppa e del funzionamento del suo sistema di controllo delle versioni, potrebbe essere necessario ricompilare e distribuire l'intera applicazione per gli aggiornamenti.

Come hai sottolineato, attualmente il tuo servizio chiamerà semplicemente il livello sottostante, duplicando efficacemente il codice. Se hai meno di 10 clienti ( totale , non in un determinato sito / distribuzione), direi che accoppi strongmente il DAL / BAL. Oltre a questo, vorrei andare al servizio.

    
risposta data 24.09.2012 - 17:22
fonte