I really hate global variables - maybe its the C# programmer in me but when I'm working in PHP I grit my teeth every time I have to do something like this:
$strUsername = $_GET['username'];
Yes, I'm grossly oversimplifying it and yes yes I sanitize all of this properly. In fact, for the framework that I built, all of the superglobals are grabbed almost at the beginning of execution and are dependency-injected from there on out.
I ran across this function in the PHP manual (you truly learn something new every day): filter_input_array().
So now, technically, I can do this instead of grabbing everything from the GET superglobal:
$GETdata = filter_input_array(INPUT_GET);
.... and so on and so forth with the others like POST, REQUEST, etc. My question is: should I use filter_input_array and so avoid the scourge of superglobals, or is there some reason to stick with them and forget about using the filter_input fun开发者_如何学编程ctions? What is everyone else's experience with this?
EDIT: I forgot one thing - the filter_input functions are blind to any script-level modifications you make to the superglobals so if I do: $_GET['cheese'] = 'puff';
trying to do filter_input(INPUT_GET, 'cheese');
later will return null. This is fine since I dependency inject everything but it could catch somebody off guard later, if they are unaware.
Using filter_input_array is still using superglobals because it's still getting its data from one of the superglobal arrays.
There's nothing wrong with getting your data from one of these arrays, its really the only way to get the data actually. You just have to make sure you escape it for whatever you're using it in.
htmlentities for html, prepared string for pdo, mysql_real_escape_String for mysql_ functions etc...
Why are global variables bad?
The common argument is, because you introduce unnesseccary dependencies to an external state.
Your solution does not prevent that, it only hides it.
A better solution would be, imho, to provide $_GET as an argument, as in
function myController($get) {
$user = Model::get_user($get['userid']);
render_view('user.html', $user);
}
myController($_GET)
as that adresses the reason why global variables are considered bad.
I use PHP superglobals, but only at the library level in my Framework. This is framework all controllers have access to the request object, which in turn access the superglobals. This allows you to write tests for your controller by making a mock request object populated with your test parameters. It's all about good OO design and good design patterns.
Accessing the superglobals directly everywhere without any abstraction in place is an anti-pattern.
I really hate those global variables as well. I would definitely use filter_input_array
and use the array whenever needed. This solves a lot of global-related bugs and prevents you from spending hours debugging these hard-to-find globals.
I think that filter_input_array
is the wtg!
I don't think someone knows perfect answer :)
Sometime I use it, sometimes I get data just like $_GET['data']
, sometimes I even use import_request_variables()
.
On some project I have special Class, that process POST
, GET
, REQUEST
and do something like this: POST::getValue('username')
or GET::getValue('session_id')
or COOKIE::getValue('last_time_seen')
...
If you really don't like superglobals, why not to write your own implementation for cleaning like vB_Input_Cleaner class here?
http://members.vbulletin.com/api/
Some years ago it was even worse, the parameter &x= in the URL appeared as global $x. Amyway, if you don't use $_GET, except in the framework, it does not exists.
精彩评论