S
Simon L. Prinsloo
Guest
In my experience, the type of context you may typically want to pass around like this tends to be bound to the client, not the server. So the singleton will always be passed in one direction, towards the server, where it is treated and handled as a singleton for the duration of the call, but needs to be discarded at the end of the call in favour of the singleton passed by the next caller. A typical use case that I can think of: Each branch has a cash book and the responsible users can only access the cash book data for their own branch. They cannot select another branch. But the internal auditor needs to access the cash book data of any branch. You could ask him in each program which branch he is working with, or you can always default it to the last one he used. In order to do this, you need to track his "working" branch in some environment variable. Legacy code typically use a global shared variable, modern code will need a singleton. This also enables both the branch user and the auditor to use common programs without forcing the branch user to enter the only possible valid value each time, since the "working branch" variable/property can be set to the user's branch. If the singleton contains a lot of data that are always needed in the business logic, you typically end up passing all of these as separate parameters to the AppServer (which later causes problems when more data is needed) or as some formatted string (which can be extended if more data is needed) with every call to the AppServer. The latter would simply use the parameters, store it in a singleton or, in traditional code, replace the values in the global shared variables with those in the parameters. If you pass the singleton from the client to the AppServer, you have the option of replacing any possible pre-existing singleton with the received object or copy the whole object's values in a simple call, rather than copying values one by one from a formatted string.
Continue reading...
Continue reading...