PHP modeli doğrulama için ortak desenleri nelerdir?

4 Cevap php

Şu anda, ben bir nesne oluşturmak ve istemci alınan get / post verilerini ayarlamak için kendi ayarlayıcıları kullanın. Ve bunun gibi () işlevi Kaydet () çağırmadan önce Validate çağırır:

//member registration
$m=new Member();
$m->setName($_POST['name']);
$m->setBirthDate($_POST['birthdate']);
$m->setAddress($_POST['address']);

$arrOfErrMsgs=$m->validate();

if(!empty($arrOfErrMsgs)){
//echo some error messages to client or redirect to a page that shows the error
exit();
}

$saveSuccess=$m->save(); //to be safe, inside this save function, it will also call validate() again before saving, so that even someone forgot to call validate() before calling save() by mistake, no dirty data will appear in the database 

if($saveSuccess){
//echo a success message to client or redirect to a success page

}else{
//echo save failed message to client (normally this should not happen unless db server suddenly fails)
}

exit();

Bu çalışır, ancak bazı alternatifler olmalı. Örneğin, belki doğrulamaları bazı ayarlayıcıları yapılabilir.

Ben en yaygın PHP model doğrulama için ne desen bilmek istiyorum?

4 Cevap

<?php

abstract class Model {

    protected $errors = array();

    public function validate() {
    	// Implement validation logic, overriden in subclasses
    }

    public function isValid() {
    	$this->validate();
    	return empty($this->errors);
    }

    public function save() {
    	if (!$this->isValid()) {
    		return false;
    	}

    	// Perform the saving operation
    }
}

class Member extends Model {

    // setters and getters and constructor

    public function validate() {
    	if (empty($this->name)) {
    		$this->errors[] = 'name can not be empty';
    	}
    }
}

$member = new Member(array(
    'name' => 'Hanse'
));

if ($member->save()) {
    // Print success messages
} else {
    // Print error messages
    print_r($member->getErrors());
}

Yukarıdaki kod olduğu gibi bir yaklaşımı tercih ederler. Size temiz ve esnek API verir.

Kontrolör modeli olmayan herhangi bir güvenilir veri işlemek gerekir, doğrulamak gerekir.

Ben modelleri doğrularken bu şekilde tavsiye etmiyoruz.

Öncelikle, kontrolör kadar sigortalanması gibi, o kadar üzerinde olmalı ve bir tamsayı olmalıdır zaman bir dize olduğunu da, girişi doğrulamak var. Ama değil iş mantığı.

Yeni bir üye oluşturduğunuzda, ben yerine yapıcı aracılığıyla tüm bilgilerin geçirerek öneririz. Setter yöntemleri sorumlu oldukları her noktası için tutarlılık kontrolleri olmalı iken bu şekilde yapıcı, GENEL modeli tutarlılığını kontrol edebilirsiniz.

Eğer firstHeardOf gibi bilgileri (onlar bir üyesi olma konum ne olursa olsun sitesi duydum ilk kez) başka bir parça olsaydı Örneğin, setter, geçerli bir tarih olduğunu sağlamalıdır ve çok az, doğum tarihinden SONRA bulunuyor en azından. Bu yöntemlerden bir sipariş sorunu oluşturur ve yöntemleri belli bir düzen içinde çağrılabilir gerektiren yerine yapıcı aramaların sıralamasını garanti etmek için kullanılır, iyi bir uygulama değildir.

Tasarruf yöntemi verileri kaydeder, artık sadece basit bir yöntem olduğunu ve gerçekten neden başka herhangi bir sorumluluk olmalıdır. En azından inşa üyesi bir Özel / korumalı doğrulama yöntemi haline yapıcı doğrulama kodunu çekin ve her iki yerde de aramak istiyorsanız olabilir nerede, hangi hala geçerli olup olmadığını kontrol çift gerekir.

Sorumluluklar, ve burada yıkmak nasıl, en azından zihnimde hızlı bir kelime:

  • Yapıcı geçerli / düzgün başlatılmamış üye nesne oluşturmak için sorumlu
  • Belirleyiciler datum için üye nesnesi içinde geçerli ayar verilerini sorumludur
  • Tasarruf yöntemi geçerli bir üye nesnesini tasarrufu sorumludur

Ben bu iş doğrulama gerçekleştirmek için mükemmel iyi bir yol olduğunu düşünüyorum. Veri (gereksiz validate() çağrı kaydetme) else true, geçersiz ise belki save() yöntemi hata mesajı ile bir dize geri dönebilirler. Bu benim şu anda almak yaklaşımdır - gerçekten sizin API tasarımı istiyorum nasıl bağlıdır rağmen. Sürece öngörülebilir ve mantıklı gibi.

Erenon yorumladı gibi, maket vs ints, tarih biçimleri, kötü niyetli kod, kontrol gibi düşük seviyeli doğrulama performans olmamalıdır - bu başka bir yere ait (örneğin, Zend_Form). Ancak gibi iş doğrulama için member must be over 21 years old, ben bir sorun görmüyorum.

etiketler