Skip to main content
Code Review

Return to Revisions

2 of 2
Commonmark migration

I can immediately see two more options, perhaps they're something you're after, perhaps not.

Option 1

Turn $data into a multidimensional array. You would end up with something such as:

...array('param1' => [$param1, \PDO::PARAM_STR], 'param2' => [$param2, \PDO::PARAM_STR]...

Pros

  • Both value data and type are paired to the key, so now you can simply refer to either with array referencing.
  • You can play with indentations and returns to find a format that suits you. It's easy enough to separate each key/value onto a new line.

Cons

  • It's more condensed, which might lead to readability issues. (Do you keep in mind the 2nd pro above though)
  • An IDE's autoformat might place it all on one line, depending on your settings.

Option 2

Have a type searching function to automatically determine the type and assign it. This could be a simple helper function with a few conditionals, each with one of the is_* variable functions.

You would want to call the function as a parameter of bindValue().

Pros

  • This would scale quite well.
  • It's easy to alter outputs and fine-tune.
  • You won't have to add the type every time you add a new key/value pair.
  • Can even check for things such as objects and handle those properly.

Cons

  • More business code and less model/data code.

I would agree that the SQLParameter is overboard. If anything, maybe one of my solutions will inspire your own.

Alex L
  • 5.8k
  • 2
  • 26
  • 69
default

AltStyle によって変換されたページ (->オリジナル) /