Naming a class that decides to retrieve things from cache or a service + architecture evaluation
- by Thomas Stock
Hi, I'm a junior developer and I'm working on a pet project that I want to learn as much as possible from.
I have the following scenario:
There's a WCF service that I use to retrieve and update data, lets say Cars. So it's called CarWCFService and has a GetCars(), SaveCar(), ... . It implements interface ICarService. This isn't the Actual WCF service but more like a wrapper around it.
Upon retrieving data from the service, I want to store them in local memory, as cache.
I have made a class for this called CarCacheService which also implements interface ICarService. (I will explain later why it implements ICarService)
I don't want client code to be calling these implementations. Instead, I want to create a third implementation for ICarService that tries to read from the CarCacheService before calling the WCFCarService, stores retrieved data in the CarCacheService, etc.
3 questions:
How do I name this third class? I was thinking about something as simple as CarService. This does not really says what the service does exactly, tho. Is the naming for the other classes good?
Would this naming and architecture be obvious for future programmers? This is my biggest concern.
Does this architecture make sense?
The reason that I implement ICarService on the CarCacheService is mainly because it allows me to fake the WCFService while debugging. I can store dummy data in a CarCacheService instance and pass it to the CarService, together with an(other) empty CarCacheService.
If I made CacheCarService and WCFService public I could let client code decide if they want to drop the caching and just work directly on the WCFService.
