Assegnazione di un nome a una classe che decide di recuperare elementi dalla cache o da un servizio + valutazione dell'architettura [chiusa]

Question

Assegnazione di un nome a una classe che decide di recuperare elementi dalla cache o da un servizio + valutazione dell'architettura [chiusa]

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

-1

Sono uno sviluppatore junior e sto lavorando a un progetto per animali domestici che voglio imparare il più possibile da.

Ho il seguente scenario:

C'è un servizio WCF che uso per recuperare e aggiornare i dati, diciamo Cars. Quindi si chiama CarWCFService e ha un GetCars (), SaveCar (), .... Implementa l'interfaccia ICarService . Questo non è il servizio effettivo di WCF ma è più simile a un wrapper attorno ad esso.

Dopo aver recuperato i dati dal servizio, voglio memorizzarli nella memoria locale, come cache. Ho creato una classe per questo chiamato CarCacheService che implementa anche l'interfaccia ICarService . (Spiegherò in seguito perché implementa ICarService)

Non voglio che il codice client chiami queste implementazioni. Invece, voglio creare una terza implementazione per ICarService che tenta di leggere dal CarCacheService prima di chiamare WCFCarService , memorizza i dati recuperati nel < strong> CarCacheService , ecc.

3 domande:

Come nomino questa terza classe? Stavo pensando a qualcosa di semplice come CarService . Questo in realtà non dice cosa fa esattamente il servizio, comunque. Il nome delle altre classi è buono?
Questa denominazione e questa architettura sarebbero ovvie per i futuri programmatori? Questa è la mia più grande preoccupazione.
Questa architettura ha senso? La ragione per cui implemento ICarService su CarCacheService è principalmente perché mi consente di simulare WCFService durante il debug. Posso archiviare dati fittizi in un'istanza CarCacheService e passarli a CarService , insieme a un (altro) vuoto CarCacheService . Se ho reso pubblico CacheCarService e WCFService , potrei consentire al codice client di decidere se eliminare la cache e lavorare direttamente su WCFService .

architecture naming services

posta Thomas Stock 22.02.2011 - 13:37

fonte

3 risposte

1

Avrei due classi, non una. Avrei il cache avvolgere il DAO. È essenzialmente il pattern Decorator , in cui la decorazione aggiunge il cacheing.

risposta data 22.02.2011 - 14:34

fonte

0

Non dico che sia perfetto, ma di solito chiamo classi che possono decidere il proprio comportamento nella cache cacheable_ _ nel tuo caso cacheablecarserviceclient sarebbe probabilmente quello che chiamo il pezzo client se lo sono seguendo correttamente il tuo esempio.

risposta data 22.02.2011 - 16:29

fonte

Leggi altre domande sui tag architecture naming services

Is Dependency Injection è uno standard in PHP e Laravel? Separazione della logica comune in un'interfaccia

score 2 · Accepted Answer

Would this naming and architecture be obvious for future programmers?

Per me ci sono troppi servizi qui. Che ne dici di

CarWCFService - > %codice%
CarWCFAdapter - > %codice%

Quindi puoi chiamare la terza classe CarCacheService (o CarCache - dopotutto, presumo, i client non vedranno il nome di questa classe concreta direttamente comunque, si occuperanno solo dell'interfaccia).

O una svolta diversa: mantieni CarService e chiama invece la terza classe CarServiceImpl .

Does this architecture make sense?

Non avrei CarWCFService implementare CarServiceProxy . Il motivo per cui lo fai è un dettaglio di implementazione del test. Mi piacerebbe solo simulare CarCacheService nei miei test unitari. (hai dei test unitari, vero?)