2009-10-29 15 views
6

Aktualnie pracuję nad aplikacją OO PHP. Mam klasę zwaną sprawdzaniem poprawności, której chciałbym użyć, aby sprawdzić, czy wszystkie przesłane dane są poprawne, ale oczywiście potrzebuję gdzieś zdefiniować reguły dla każdej właściwości do sprawdzenia. W tej chwili używam tablic podczas budowy nowego obiektu. np .:Walidacja obiektów PHP

$this->name = array(
'maxlength' => 10, 
'minlength' => 2, 
'required' => true, 
'value' => $namefromparameter 
) 

Jedna tablica dla każdej nieruchomości.

Wywołałbym wtedy metodę statyczną z klasy sprawdzania poprawności, która przeprowadzałaby różne sprawdzenia w zależności od wartości zdefiniowanych w każdej tablicy.

Czy jest to skuteczniejszy sposób na zrobienie tego? Wszelkie porady są mile widziane. Dzięki.

Odpowiedz

8

Wiem, że tablica asocjacyjna jest używana powszechnie do konfigurowania rzeczy w PHP (nazywa się to magic container wzorzec i jest uważana za złą praktykę, btw), ale dlaczego nie stworzysz wielu klas walidatorów zamiast tego, z których każdy może obsługiwać jeden reguła? Coś takiego:

interface IValidator { 
    public function validate($value); 
} 

$validators[] = new StringLengthValidator(2, 10); 
$validators[] = new NotNollValidator(); 
$validators[] = new UsernameDoesNotExistValidator(); 

Ma to wiele zalet w stosunku do realizacji z wykorzystaniem tablic:

  • Można dokument im (bardzo ważne), PHPDoc nie może analizować komentarzy dla kluczy tablicy.
  • Kod staje typo-sejf (array('reqiured' => true))
  • Jest w pełni OO i nie wprowadzać nowych pojęć
  • To jest bardziej czytelny (choć dużo bardziej gadatliwy)
  • Realizacja każdego przymusu można znaleźć intuicyjnie (to nie jest w funkcję 400-line, ale w odpowiedniej klasie)

EDIT: Oto link to an answer I gave do different question, ale to przede wszystkim zastosowanie do tego jak dobrze.

+0

Dobry punkt z dokumentacją! –

+0

Dzięki, wcześniej nie słyszałem o interfejsach. Sprawdzę je! – Dan

0

Po użyciu OO byłoby czystsze, gdybyś używał klas do sprawdzania poprawności właściwości. Na przykład.

class StringProperty 
{ 
    public $maxLength; 
    public $minlength; 
    public $required; 
    public $value; 
    function __construct($value,$maxLength,$minLength,$required) 
    { 
    $this->value = $value; 
    $this-> maxLength = $maxLength; 
    $this-> minLength = $minLength; 
    $this-> required = $required; 
    } 
    function isValidat() 
    { 
    // Check if it is valid 
    } 
    function getValidationErrorMessage() 
    { 
    } 
} 

$this->name = new StringProperty($namefromparameter,10,2,true); 
if(!$this->name->isValid()) 
{ 
    $validationMessage = $this->name-getValidationErrorMessage(); 
} 

Korzystanie z klasy ma tę zaletę, że wewnątrz niej jest enkapsulacja, której nie ma tablica (w zasadzie struktura).

0

Być może zainspiruje Cię Zend-Framework Validation.

więc zdefiniować Master:

class BaseValidator { 
    protected $msgs = array(); 
    protected $params = array();  

    abstract function isValid($value); 
    public function __CONSTRUCT($_params) { 
     $this->params = $_params; 
    } 
    public function getMessages() { 
     // returns errors-messages 
     return $this->msgs; 
    } 
} 

A potem budować niestandardowe weryfikatorów:

class EmailValidator extends BaseValidator { 
    public function isValid($val=null) { 
     // if no value set use the params['value'] 
     if ($val==null) { 
      $val = $this->params['value']; 
     } 
     // validate the value 
     if (strlen($val) < $this->params['maxlength']) { 
      $this->msgs[] = 'Length too short'; 
     } 
     return count($this->msgs) > 0 ? false : true; 
    } 
} 

Wreszcie Twój inital tablica może stać się coś takiego:

$this->name = new EmailValidator(
     array(
      'maxlength' => 10, 
      'minlength' => 2, 
      'required' => true, 
      'value' => $namefromparameter, 
     ), 
    ), 
); 

walidacja może następnie być zrobić tak:

if ($this->name->isValid()) { 
    echo 'everything fine'; 
} else { 
    echo 'Error: '.implode('<br/>', $this->name->getMessages()); 
}