UI, Business Logic Layer, Data Layer e dove mettere i servizi web

Question

Stiamo sviluppando un'applicazione web. Vogliamo riutilizzare il lavoro che svolgiamo qui per un'applicazione diversa che utilizzerà lo stesso database e utilizzare le stesse regole aziendali per la lettura e la scrittura di tale database.

cui il design sarebbe più corretto

1. Avere i servizi web di chiamata UI, che userebbero oggetti di business che contengono la logica di business, che parlare con il livello di accesso ai dati.

2. L'interfaccia utente utilizza gli oggetti business contenenti la logica aziendale, che chiamerebbe i servizi Web, che quindi parlerebbero con il livello di accesso ai dati.

3. Gli oggetti aziendali utente dell'interfaccia utente che contengono la business logic, che parlerebbero con il livello di accesso ai dati.

Answer 1

Dalla descrizione, non è stato fornito un motivo per cui è necessario utilizzare un livello di servizio Web. Supponendo che il tuo database sia raggiungibile dal tuo sistema di interfaccia utente, cioè all'interno della stessa rete dietro il tuo firewall, un livello di oggetti di business di base che il codice dell'interfaccia utente del tuo sito Web (lato server, sto assumendo) utilizzerà soddisferà i tuoi requisiti.

Immettere un livello di servizio Web quando la distanza tra il sistema di interfaccia utente e il livello dati inizia a superare i confini che un livello di accesso ai dati o il livello della logica aziendale inizierebbero a incontrare difficoltà.

Answer 2

In termini di design "corretto" o meno, non è davvero possibile dare una risposta del 100% alla correttezza di un design senza il contesto completo. Quali sono i requisiti (funzionali e non funzionali)? Quali obiettivi di progettazione vuoi realizzare? Quanto è importante ogni obiettivo?

L'unico obiettivo della domanda è che si desidera riutilizzare la business logic con un'altra applicazione. Quando voglio riutilizzare la logica di business di un'applicazione in un modo standard, scelgo i servizi web. Quindi, basandomi unicamente sul tuo unico requisito, direi che l'opzione 1 (UI-> Web Service-> Business Layer-> Data Layer) è una buona scelta.

Answer 3

Check Out: http://www.icemanind.com/layergen.aspx

Il modo in cui dovrebbe andare è, avete il vostro livello di interfaccia utente sulla parte superiore, la parte dati sul fondo e il vostro livello di business tra i due. Ogni livello può comunicare solo con il livello sottostante. Quindi l'interfaccia utente parla solo con il livello aziendale ... il livello aziendale parla solo con il livello dati. L'interfaccia utente non deve mai parlare con il livello dati e il livello dati non deve mai interagire con l'interfaccia utente.

A meno che non si abbia un motivo per utilizzare un servizio Web, non lo farei.

Answer 4

Direi il terzo. Tendo a pensare ai servizi Web come a un altro livello di presentazione.

Pensa in questo modo: hai un'interfaccia utente Web, che chiama il codice del tuo livello aziendale per fare cose come creare un nuovo utente (User.Add), trovare tutti i prodotti che corrispondono a una determinata descrizione (Products.FindByDescription), ecc.

È ora possibile riutilizzare lo stesso codice del livello aziendale per creare una serie di servizi Web pubblici per terze parti da utilizzare. Può esserci un metodo che aggiunge un utente - che chiama il tuo metodo interno User.Add(), un altro per trovare prodotti, ecc.

Quello che si ottiene è un insieme parallelo di presentazioni/interfacce agli stessi dati sottostanti e alla logica aziendale.

Dietro le quinte (totalmente fuori dal campo dei servizi Web o dei livelli dell'interfaccia utente), il livello aziendale chiama un livello di accesso ai dati che si occupa di interrogare fisicamente il database. Se dovessi passare a un DBMS diverso, dovresti idealmente (e in teoria) essere in grado di ricostruire il livello dati per il nuovo database e fare in modo che tutto funzioni semplicemente.

Il tuo livello aziendale contiene le regole come un nome utente deve essere lungo da 4 a 15 caratteri; gli utenti possono solo cercare e caricare prodotti che si trovano in un negozio a cui hanno accesso; ecc.

Se si decide di modificare una regola aziendale, ad esempio se un utente è autorizzato a cercare prodotti in qualsiasi negozio nel proprio stato, lo si cambia in una volta e non è necessario toccare il servizio Web o UI per farlo funzionare.

Answer 5

Non mescolare design logico con design fisico. La progettazione logica opera su livelli e design fisico: livelli. Il servizio Web non è un livello. È semplicemente un livello. Nella progettazione logica esiste un approccio standard: livello UI-> livello BL -> DAL Nella progettazione fisica tutti i livelli possono risiedere all'interno di un'applicazione lato client che collega il database locale o possono essere distribuiti su livelli remoti. Ma per le applicazioni distribuite di solito viene aggiunto un altro livello: il livello dell'applicazione, che si nasconde dalla comunicazione del livello BL sul filo.

Answer 6

Logicamente, i servizi Web appartengono al livello dell'interfaccia utente. Pensa che "Utente" non è solo un essere umano ma un altro sistema e diventa chiaro. Mantenere una rigorosa separazione delle preoccupazioni tra questi livelli logici ti consentirà di implementare e mantenere facilmente la tua applicazione.

Answer 7

Sentite qualcosa sul livello di servizio? Penso che sia possibile utilizzare un livello di servizio per le transazioni e le operazioni e l'utilizzo di un livello facciata consente di isolare e gestire l'accesso dall'interfaccia utente al livello di accesso ai dati direttamente o indirettamente dopo aver visitato il livello aziendale. dipende dalle tue esigenze.