È possibile creare un livello di business logic RESTful?

Question

Ho costruito un servizio RESTful per il Data Access Layer (DAL) della mia architettura:

POST http://example.com/data/User 
GET|PUT|DELETE http://example.com/data/User/{UserId} 

Tuttavia, per il livello Business Logic (BLL), un secondo servizio non RESTful è utilizzato:

POST http://example.com/accountapi/register 
POST http://example.com/accountapi/login 

Questo servizio BLL, invece di effettuare chiamate al servizio DAL, comunica direttamente al database.

Come miglioreresti questa architettura?

1. Se il servizio BLL chiama il servizio DAL?
2. Devo abbandonare il servizio DAL e solo esporre il servizio BLL?
3. Devo, in qualche modo, iniettare la logica di business sul mio servizio DAL RESTful? Se sì, come?

Answer 1

(1) Evitare di avere la vostra (non-REST) ​​servizio web livello di logica di business compiere ulteriori richieste (RESTful) HTTP sullo strato di accesso ai dati. Fare ciò naturalmente sarebbe meno efficiente rispetto alle chiamate al metodo diretto. Ma, cosa ancora più importante, richiederebbe la distribuzione dei servizi Web BLL e dei servizi Web DAL su istanze separate del server Web (o cluster separati). Altrimenti puoi avere un caso in cui tutti i i tuoi thread di lavoro HTTP sono impegnati a provare a fornire risposte BLL, e ognuno è bloccato in attesa infruttuosamente per un thread di lavoro HTTP libero per servirsene una risposta DAL. Questo può portare a bancarelle (se si esegue il timeout/riprovare l'elaborazione) o deadlock definitivi (se non lo si fa).

(2 e 3) Se i client del servizio Web richiedono sia la business logic che l'accesso ai dati, fornire tali servizi come un insieme unificato di servizi. Internamente entrambi dipendono dalle stesse chiamate al metodo del livello di accesso ai dati: è solo che le implementazioni dei servizi Web orientate ai dati effettuano una sola chiamata al livello di accesso ai dati mentre le implementazioni dei servizi Web orientate alla logica aziendale possono effettuare molte chiamate DAL. Tuttavia, si desidera assolutamente strutturare separatamente i livelli BLL e DAL al di sotto del livello del servizio Web.

Mi piace pensare ai servizi Web come solo la parte del livello di presentazione orientata agli "utenti" che risultano essere altri programmi.

Answer 2

1. Se questa è la stessa applicazione, allora probabilmente si dovrebbe avere lo strato BLL chiamare lo strato DAL direttamente nel codice invece di utilizzare di nuovo una chiamata di servizio. Ciò lo manterrebbe più performante pur mantenendo gli obiettivi fondamentali del codice separati (alta coesione).

2. Probabilmente sì. I servizi dovrebbero generalmente essere componenti granulari che svolgono una funzione aziendale. Salvare un utente nel database non è una funzione aziendale, è un'implementazione specifica. La funzione Register astrae questa nozione in una funzione aziendale. Il livello BLL può quindi applicare elementi come la sicurezza della password, la crittografia della password, l'univocità dei nomi utente, ecc. Che non sono direttamente correlati all'accesso ai dati.

3. Probabilmente no. Vedi # 2.

Answer 3

Per rispondere alla domanda principale. No, non proprio. Per rispondere alle domande secondarie. Nessuno dei precedenti.

Le architetture basate su REST non si adattano perfettamente al modello standard a 3 livelli. La visione semplicistica del modello a tre livelli è simile al seguente:

Presentation Layer < -> Affari Logic strato < -> Data Layer

Consideriamo per un momento la rottura del livello di presentazione in due parti,

Rendering strato < -> Interfaccia utente Content < -> BLL < -> DAL

Se si pensa a un'applicazione Web normale, il browser acquisisce contenuto HTML, CSS e Javascript e li rende visivamente in un browser. È il livello del contenuto dell'interfaccia utente a cui si applicano i vincoli REST. Questo è più ovvio se pensi al vincolo ipermediale. Le interfacce REST sono da intendersi per navigare come le interfacce utente. Le interfacce REST restituiscono presentazione s di risorse.

Le interfacce REST devono restituire il contenuto dell'interfaccia utente indipendente da come verrà visualizzata l'interfaccia utente.

REST client < -> REST Interfaccia < -> BLL < -> DAL

A mio parere i clienti REST sono disponibili in due forme, o molto sottili tipo di supporto motori di rendering (ad esempio i browser Web) o screen scrapers (spider, mashups). Uso il termine "raschia schermo" in modo approssimativo, perché se si scelgono i tipi di supporto con saggezza, dovrebbe essere banale per il cliente estrapolare i dati dal contenuto dell'interfaccia utente.

Qualsiasi tentativo di esporre i livelli di business logic come interfacce REST di solito ha alcuni effetti. Gli sviluppatori finiscono per chiedere come fare le transazioni in REST. Finiscono per creare enormi quantità di accoppiamento tra il client e l'interfaccia BLL a causa della necessità di esporre rappresentazioni semanticamente ricche. Dimenticano tutto il vincolo ipermediale, perché molte di quelle informazioni di collegamento non sono disponibili nel livello della logica aziendale. E iniziano a lamentarsi del sovraccarico delle prestazioni di HTTP e tipi di contenuto basati su testo.