How can I use a proxy template to replace a singlet?

This is in response to some comments on what's so bad about singles

There it was suggested that the proxy template can be used instead of a singleton for caching database data. But I don’t see the benefits, and in fact the singleton seems more “manageable”.

Let me elaborate on the problem. Suppose you have a database with a large data set that never changes, so it can be read only, why does the proxy template best model this data cache than singleton?

(PS: if you are going to say "because its more" verifiable "!" - please specify, I'm still used to these concepts)

Thanks for your help!

+8
design-patterns singleton
Jan 19
source share
3 answers

Disclaimer: I speak in java terms here

Singleton is now considered an antipater, mainly because many people have abused recently, as they are a quick and convenient way to exchange data throughout the application, which is a somewhat excessive extension of the design pattern, which is more suitable for providing access control to a shared resource.

consider the standard output of the program: access to this resource must be protected by one access point to ensure synchronization of records, so you have, for example, System.out as a static instance in java.

the problem is that when you start singleton, you need to know all the detailed details about what you are doing, because you make many strict assumptions in your singleton class, the most important of which is the only class in the system. then you will start using it, believing that it will always be one entry point to your resource, and then an unpleasant error occurs because your class is now deployed to the ejb server, and each ejb context has its own singleton, plus one more singleton for each jsp that was rebooted from the server, plus one singleton for every time your singleton was serialized and deserialized (since you probably forgot to override the readResolve () method).

therefore, therefore, the singleton should be used with great attention and is now considered an antipatter, despite the fact that it is completely useful for their intended use.

in the case of a database cache, it would be a better approach for each class to need a cache using a proxy server for this “cache” resource, so you can add the “find the resource” logic within the proxy itself instead of binding the logic to retrieving a cache single that may or may not work depending on the environment.

therefore, in a few words using singleton as a means of sharing a resource, this is bad because you hard code the resource search method (and ignore single traps), having a single-color resource control for synchronization purposes is completely acceptable.

think of semaphores, they only work if you can always get the same semaphore. in this latter case, the problem may be accessing the singleton from wherever you need to access this semaphore: here you will need some class to wrap the singleton and provide finer control over the life cycle of the semaphore itself.

proxies are designed to cover the role of "providing a resource in the system", whether it be a single application, a client server system, various components of the same system, etc., with the added benefit that using èrpxy the resource search method is opaque. you can provide them with a singleton containing a hash map of cached values, you can access memcached on the network, you can have them read csv during tests, without changing the way they are called from the application.

+7
Feb 01 '10 at
source share

In my opinion, no or no. A class can simultaneously implement several design patterns. I would say that a class that implements access to an external database is in any case a proxy (in this case, a remote proxy). If you think caching has extra functionality, it is also a Decorator.

So the real question is: should it be Singleton? Suppose there is only one external database. Is only one CachingDBProxy needed? I would say it depends on usage:

If several clients access similar data, they can clearly win if they use the same CachingDBProxy. The data needed by one client may already be needed by another client, so it can be retrieved from the cache instead of performing expensive access to the database.

On the other hand, some customers can access completely different pieces of data. Thus, if we assume that CachingDBProxy caches a limited amount of data access by one group of clients, it may discard the data still needed by another group of clients, which will lead to a decrease in cache performance. In this case, it may be prudent to have several CachingDBProxies, although there is only one database (this assumes, of course, that parallel access is possible).

So how much CachingDBProxies should be depends on usage. CachingDBProxy should not limit its use without a valid reason, therefore, it should not ensure that only one instance exists. So, in this case, CachingDBProxies should not be Singleton, IMHO. Only customers can know how many CachingDBProxies are right for them.

On the other hand, if we have a proxy server for a specific resource that can only handle one access at a time, it could be Singleton. But this is a great case from the above case. Here, the request comes directly from the area to which the Proxy responds (its purpose is the access channel to this particular resource).

+2
Jan 30
source share

I can only imagine that a proxy template is used for a proxy server between cached data and data loading (aka lazy loading).

Sorting:

class DbProxy { private static Data cache = null; // Sort-of Singleton public static Data GetData(String query) { if (DbProxy.cache == null) { // Data = Do Stuff to read Data DbProxy.cache = Data; } return DbProxy.cache; } } 

The advantage is that in the code using this code, you do not need to take care that the data already exists, it just needs to call GetData and do it.

/ * Disclaimer: the code is not valid, it is just pseudo for demo purposes only * /

0
Jan 19 '10 at 15:17
source share



All Articles