Some nice things about fastcgi/speedycgi (http://daemoninc.com/speedyc
+gi/)
*) suexec works with it (I consider this huge)
*) don't have to worry about running multiple web servers (one for
images/static and one for dynamic).
*) one process can't pollute another's.
*) can make changes to .pm's and they are seen as soon as
you "touch" the main file. (for speedy, I believe fcgi works
a little different).
*) bad code doesn't take away the httpd's ability to serve files.
*) can probably be hacked to use internet domain sockets as
opposed to unix domain so that we can run the cgi's on
a different box. (fastcgi already does this, speedy does not)
*) the architecture just *feels* better to me than having a perl
interpreter inside the webserver (but my mind is still open).
*) fastcgi is language independant (speedy is not)
why would you never use Class::DBI?
Because IMO, it places the code in the wrong place and encapsulates objects in the wrong way.
If you are going to back objects with an SQL DBMS, then the SQL should be in stored procedures and object methods should call those. I was told a long time ago that the secret to using SQL/RDBMSs is in getting the dbm to do as much of the work for you as possible.
Instantiating all your data as objects in your program, leaves you faced wih much higher transmission costs if you update after every local change, or you risk concurrency issues if you cache locally.
As always, that is just my opinion. I am not trying to detract from other's use of these things. Just expressing my own preferences.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
|