Re^3: Best practices passing database handles, cgi objects, etc.

Sigh.

What is wrong with keeping a CGI object and a CGI::Session object as global state/variables/whatever? They are request-dependent. They need to be overridden at the start of each request. Are you planning to serve HTTP requests in a non-serial manner or something?

The database handle: There's usually one per process. One FCGI-ish process usually handles a single web site. What is the problem storing a handle globally in such a case? Certainly, if you plan to connect to multiple databases in your program you don't use that design, but you have to concoct pretty elaborate scenarios to get to a point where this single-handle thing falls down.

And before you say 'unit testing', you can override those functions, can't you?

Comment on Re^3: Best practices passing database handles, cgi objects, etc.

Replies are listed 'Best First'.
Re^4: Best practices passing database handles, cgi objects, etc. by tobyink (Canon) on Feb 18, 2014 at 15:46 UTC
What's wrong? It hard-codes the assumption that one request equals one process, and thus makes it doubly hard to move on to a solution where multiple requests can be served from a single process. Whatsmore, it limits your objects and functions to only being used in CGI scripts. Some of these objects may be generically useful, for example, useful in cron jobs that perform various routine maintenance related to the website. Even if you ignore all that, there are valid reasons to make sure that sessions are passed around from function to function. For example, you may wish to allow the admin user, once they're logged in, to take over any other user's session - to help diagnose website problems for example. Doing that sort of thing is much easier if the session is not a singleton. `use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name`	[reply]

Replies are listed 'Best First'.

Re^4: Best practices passing database handles, cgi objects, etc.
by tobyink (Canon) on Feb 18, 2014 at 15:46 UTC

What's wrong? It hard-codes the assumption that one request equals one process, and thus makes it doubly hard to move on to a solution where multiple requests can be served from a single process.

Whatsmore, it limits your objects and functions to only being used in CGI scripts. Some of these objects may be generically useful, for example, useful in cron jobs that perform various routine maintenance related to the website.

Even if you ignore all that, there are valid reasons to make sure that sessions are passed around from function to function. For example, you may wish to allow the admin user, once they're logged in, to take over any other user's session - to help diagnose website problems for example. Doing that sort of thing is much easier if the session is not a singleton.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

[reply]