In general, you should only use public for static pages, or pages that return the same data no matter what user is making the request. This is a problem if you have an authenticated application that is displaying private data.
The problem with Cache-Control: Public is that the response may be cached and displayed to a different user. Having said that, what is the additional advantage of have Cache-Control: public? In that case, there is even less privacy involved because it is unlike where there are a lot more variety of products such as books for which a user can really care more about privacy issue. What if it is a website where user can be logged in, but the website only search for health products like fish oil and vitamins, and so forth. If that location wants to be "bad", it really doesn't need to care about the Cache-Control: private anyway. What if the website is like, but the user is anonymous, then probably there is not much privacy issue? What if the user is logged in, could there be privacy issue, because the data passes through places and the data is visible. What is the risk of making it public? If it is public, which extra places can cache the content - would it be a proxy server, for example? From somewhere.The Cache-Control HTTP/1.1 header can specify max-age as well as whether the cache content can be public or private, indicating whether intermediate cache can cache the content.įor example, Ruby on Rails's expires_in() defaults to using Cache-Control: private The really important test, the filtering method, will be there and completely abstracted from the detail of GetAll(). You're going to end up with tests that fail once in a blue moon and you'll never really understand why.Īnd, having made the changes I've suggested above, there's really not that much logic to test in there. Like, just removing stuff from it when it gets too full, for example. The framework does things with it that are out of your control. Now the question becomes: Should I test that CachedProductRepository? I suggest not.
#Problem with private cache control how to
It should be obvious how to adapt.)Īnd, in your ProductManager tests IProductRepository repo = MockRepository.GenerateStrictMock() (If you're using an IOC container, even better.
New CachedProductRepository(new SqlProductRepository())) This is incredibly useful later when you get a confusing bug that you suspect is a result of the cache. You can now instantiate the ProductManager with either of those Repositories and get caching. See how you've removed the repository implementation knowledge from the ProductManager? See also how you've adhered to Single Responsibility Principle by having a class that handles data extraction, a class that handles data retrieval and a class that handles caching? if not then call GetAll() on inner repository Public CachedProductRepository (IProductRepository productRepository) Private IProductRepository ProductRepository Just have a Repository and a Caching Wrapper that use the same interface and inject that into the calling class. However, if this is the only thing you're caching, you don't need to go as far as having an AOP framework. Using tools like PostSharp, you can set it up so that any method marked with a chosen attribute will be cached. It's one of the few things that it's very good at. Second, wrap the class that gets the data from the database (or wherever) in a caching wrapper.ĪOP is a good technique for this. It no longer cares where you're getting it from. This makes testing your filtering class nice and easy. That it retrieves from the cache is an implementation detail of the repository and shouldn't be known by the calling code. The Single Responsibility Principle is your best friend here.įirst of all, move AllFromCache() into a repository class and call it GetAll().
0 kommentar(er)
