Ben modelinde POST-Parametreler erişmek veya denetleyicisi yöntemi, argüman olarak geçmesi gerekir?

4 Cevap php

Ben yaklaşık 20 POST-parametreleri işlemek zorunda ve ben nerede yapmak için emin değilim.

Ben model üzerinde yöntemin bir argüman olarak her tanımlamak ve yöntemi denir denetleyici onları geçebileceği. Bu çalışmanın yeraldığını neden ve nedeniyle argümanların sayısına, işlev çağrısı daha az okunabilir olur.

Yoksa modeline yöntemini çağırın ve sadece doğrudan parametreleri erişebilir.

Argüman olarak parametreleri geçirerek bana daha fazla işlevi erişen hangi parametreleri üzerinde kontrol ve belgeleri verecek kendine daha açıklayıcı olur. Mevcut her çağrıyı kırmak için değil ancak yeni parametreler sonradan ilave edildiği takdirde, bunlar, yöntem çağrısı sonuna eklenecek gerekir. Ben bu olursa argümanlar mantıksal gruplandırılmış olamaz gibi bu, bir kaç kez oldukça kafa karıştırıcı olacağını düşünün.

Ben modeli parametreye erişmek, hiçbir parametre yöntem çağrısı terser yapma, denetleyicisi modeline geçti gerekir. Kolayca ve sınırlama olmadan eklenebilir veya çıkartılabilir Ama ben, erişilen parametreleri üzerinde hiçbir kontrole sahip. Bu, diğer geliştiricilerin büyük bir disiplin gerektirir, ve er ya da geç birisi "sadece (add düzeltme | | değişikliği) bu gerçek hızlı" bağlı olduğu, çünkü o bağlıdır sevmediğim.

I'm not sure which way to go. I tend to just do it all in the model, as this is faster to write, seems easier to maintain (no argument chaos) and conceptually fits better into my view of a model. On the other hand, I'm not sure my view of a model is correct, and if it will end in chaos if I depend on the other developers to always update the documentation after each change.

Peki, ben ne yapmalıyım?

4 Cevap

Peki, neden sadece model bu yöntemde bir parametre olarak (ilişkisel) dizisi kabul, ve sonra o bütün $ _POST dizi geçemez? En azından benim görüşüme göre, bu kapsüllemeyi kırmak olmaz.

EDIT: Ve bunun için ilişkilendirilebilir diziler kullanarak sevmiyorum, sen de (C yapılar gibi sadece veri taşımak için kullanılan nesneler,) sözde "Plain Old Objects" kullanabilirsiniz. Örneğin, bu bir gönderilen kayıt formunu kurtaran ise:

class UserData
{
    protected $name;
    protected $username;
    protected $password;

    public function getName() { /* <...> */ }
    public function setName() { /* <...> */ }
    /* other accessors go here */
}

class UserController extends Controller
{
    public function register()
    {
        $userData = UserData::create()
            ->setName($_POST['name'])
            ->setUsername($_POST['username'])
            ->setPassword($_POST['password']);
        Users::add($userData);
    }
}

Bu Kullanıcılar sıkı yazarak kullanmak için izin verecek :: ekleyin ve aynı zamanda dokümantasyon sürecini kolaylaştırmak.

Ben aynı sorun ile mücadele ettik, ve ben ile geldi çözüm, esnek benim kod yeniden kullanılabilir tutar ve ön ucuna değişikliklerin hoşgörülü: Ben belirleyiciler kullanarak gibi. Tabii ki, her bir değer için bir ayarlayıcı olan bir ağrı olduğunu, öyle mantıklı şekillerde verileri gruplandırma yardımcı olur:

$user = new User();
$user->setName($_POST['lastName'],$_POST['firstName']);
$user->setAddress($_POST['address1'],$_POST['address2'],$_POST['city'],$_POST['state'],$_POST['zip']);

Sen noktası olsun. Bir kez değişkenler nesneye kaydedilmiş, daha sonra nesnenin yöntemleri tüm bu değerleri kullanabilirsiniz.

Superglobals üzerinde modelleri güvenen yapmak çok esnek değildir. Ayrıca, ağrı test ünitesi sağlar.

I a similar question Bir süre önce yanıtladı. Bunları örneğin geçmelidir imho olarak zaten bir ilişkisel dizi (ve önce tüm güvenlik denetimleri yapmak) olarak önerilmiştir. Bu şekilde kolayca clases yeniden kullanabilirsiniz.

Kontrolör. Istek veri ve model manipülasyon aynı şey değildir çünkü. Modeli istek veri tabanlı mantığı koyarak böylece tüm diğer olası istekleri için gerekli, ve kötü şu olacak

etiketler