Come refactoring servizi in API, repository e caching (. NET)?

Question

Come refactoring servizi in API, repository e caching (. NET)?

#1 da (3 voti)

2

Sto lavorando a un progetto .NET con, che è iniziato come un prototipo che ora deve essere scalato. Abbiamo lo stack ASP.NET MVC con Entity Framework (prima il codice).

Mi piacerebbe sapere come ridimensionarlo in una "architettura corretta" con API, repository che gestisce la cache e così via probabilmente.

Nota : Non sto cercando una discussione (che non è destinata a succedere su questo sito), ma solo come questo è solitamente risolto.

Situazione oggi:

Abbiamo un sito web, un progetto di servizio, un progetto di modello e un progetto di database:

Quindi,inpratica,ilnostrositoWebutilizzal'assemblyServizio,ModelloeDatabase.IlserviziorestituisceglioggettiModel,cherecuperadall'utilizzodirettosuContext.cs.

Quindi,inpratica,potremmoadesempiochiamareCustomerServicenelprogettoServizio,chederivadaICustomerServicedalprogettoModello.QuestochiamerebbedirettamenteContextnelprogettoDatabase,chequindirestituiràunoggettoCustomerdalprogettoModello.

Problemiprincipaliconesperienzaoggi:

Lalogicaaziendale,lalogicadimemorizzazionenellacacheelalogicadeldatabasenonsonoseparate,maunagrandepilainunservizio
Impossibileutilizzarefacilmenteunnuovocaching,databaseosimili.
UnsaccodiproblemidiincoerenzaconglioggettiDB,collegati/distaccatidirettamentedaEntityFramework

Ilmiomododipensare:

Stavoconsiderandoun'architetturacomequesta:

Dove:

L'API avrebbe i suoi modelli di visualizzazione che funzionano come le nostre risorse che il consumatore dell'API si aspetta
Il livello di servizio consentirebbe al repository di gestire tutte le attività del database.
Saremo in grado di decorare gli oggetti del modello con la memorizzazione nella cache

Ma questo mi lascia un sacco di domande:

Questa architettura ha persino un senso remoto?
Quali oggetti verrebbero iniettati dove? Un servizio potrebbe iniettare un repository quindi un CustomerRepository che deriva da un IRepository ? Come viene effettivamente effettuata / chiamata la memorizzazione nella cache?
Questo mi lascia con 3 rappresentazioni di un oggetto. Modello, viewmodel API e viewmodel del sito web - sembra un po 'di tempo
Dove posso trovare alcuni esempi a riguardo che mi aiuteranno?

architecture api repository .net asp.net-mvc

posta Lars Holdgaard 24.02.2016 - 13:58

fonte

1 risposta

Leggi altre domande sui tag architecture api repository .net asp.net-mvc

Autenticazione del cliente in un sito Web Come includere la stima e il suo effetto sulla prioritizzazione con Kanban?

score 3 · Accepted Answer

Does this architecture even make remotely sense?

Mi sembra ragionevole. Hai identificato correttamente i livelli necessari e quale comportamento appartiene a ciascuno di essi.

Which objects would be injected where? Would a service inject repository so a CustomerRepository that derives from a IRepository? How is the caching actually done / called?

Sono abbastanza sicuro che stai parlando dell'iniezione di dipendenza? In tal caso, sì, il livello di servizio inietterebbe il livello repo e il livello api inietterebbe il livello di servizio. Praticamente dovrebbe essere iniettata praticamente ogni dipendenza da qualcosa che fa logica di business per il sistema, in modo da poter testare l'unità.

Suggerirei di iniziare con una cache di database diretta, se non ne possiedi già uno, e quindi magari aggiungendo una cache di livello superiore se hai ancora dimostrato problemi di prestazioni nella produzione. Se la tua API è RESTful, potresti fare un passo più in là e usare un proxy di caching come calamaro in congiunzione con le intestazioni di cache correttamente impostate. La praticità di questo dipenderà dal tuo stack: per esempio, NHibernate ha il supporto per la memorizzazione nella cache L2.

This leaves me with 3 representations of an object. Model, API viewmodel and website viewmodel - seems quite timeconsuming

Yup. Il compromesso è più tempo per una maggiore flessibilità. Oltre al problema allegato, una singola rappresentazione legata a tutti e tre i livelli potrebbe essere molto limitante in seguito. Ad esempio, non puoi decidere di far rilasciare all'API una singola risorsa che è una combinazione di due o più tabelle di database. Qualsiasi modifica alla rappresentazione avrà un impatto sull'intera applicazione, che potrebbe non essere auspicabile. Potresti anche scoprire, nel tempo, che le informazioni specifiche del livello si insinuano nella tua rappresentazione, aggiungendo dipendenze che in realtà non appartengono agli altri livelli.

Where can I find some examples about this that will help me?

Fuori ambito. :-( Google è tuo amico? Prova qualcosa come .net n-tier example . In alternativa, se preferisci il codice reale, puoi trollare github e vedere se c'è qualcosa su cui lavorare.