Timeline for So Singletons are bad, then what?
Current License: CC BY-SA 2.5
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 27, 2011 at 4:18 | comment | added | SingleNegationElimination | +1 for transparent caching. If you can perceive the cache (in ways other than it's speedup) then it's not a cache. | |
| Jan 27, 2011 at 3:24 | comment | added | quentin-starin | @Bobby Tables: then your situation isn't as dire as it seemed. That Singleton (assuming you mean a static class, not just an object with an instance that lives as long as the app) is still problematic. It's hiding the fact that your data providing object has a dependency on a cache provider. It is better if that is explicit and externalized. Decouple them. It is essential for testability that you can easily substitute components, and a cache provider is a prime example of such a component (how often is a cache provider backed by ASP.Net). | |
| Jan 27, 2011 at 0:52 | comment | added | Bobby Tables | The caching IS essentially an implementation detail. There is an interface through which data is queried, and the objects getting it don't know if it came from the cache or not. But underneath this cache manager is a Singleton. | |
| Jan 27, 2011 at 0:38 | history | edited | quentin-starin | CC BY-SA 2.5 |
added 1327 characters in body
|
| Jan 27, 2011 at 0:30 | comment | added | Loki Astari | I am with qstarin here: The objects accessing the data should not know (or need to know) that the data is cached (that is an implementation detail). The users of the data merely ask for the data (or ask for an interface to retrieve the data). | |
| Jan 27, 2011 at 0:27 | comment | added | Bobby Tables | <cont> It essentially IS transparent. In the sense that there is a callback from the server if certain required data isn't cached yet. But the implementation (logically and physically) of that cache manager is a Singleton. | |
| Jan 27, 2011 at 0:26 | comment | added | Bobby Tables | There is a gigantic amount of data that certain screens might need, but don't necessarily need. And you don't know until user actions have been taken which define this - and there are many, many combinations. So the way it was done was to have some common global data that's kept cached and synced in the client (mostly obtained at login), and then subsequent requests build up the cache more, because explicitly requested data tends to be re-used again in the same session. The focus is on cutting down on requesting to the server, hence the need for a client side cache. <cont> | |
| Jan 27, 2011 at 0:17 | history | answered | quentin-starin | CC BY-SA 2.5 |