Modelleri doğru şekilde nasıl tasarlanacağı: Nesne yönelimli ya da "Paket" odaklı?

3 Cevap php

Ben OOP'deki (a sınıfı) her nesne bir "şey", örneğin olmak istediğini biliyorum. kullanıcı, validator vb

Ben farklı parçaları birbirleri ile nasıl etkileşimde, MVC hakkında temel biliyorum.

Ancak, ben MVC modelleri geleneksel OOP tasarımına göre tasarlanmış olmalıdır eğer, o (solüsyon 2) her modeli veritabanı / tablo / satır olmalı, demek ki acaba?

Ya da aynı tabloyu etkileyen yöntemleri toplamak için daha fazla gibi niyeti veya ilgili tabloları bir demet (çözelti 1).

i "REZİL" Bir Kişiyi edebilmek ve bunu kaldırmak / a CRUD-mümkün Temas Grubu / eklemek istediğiniz CodeIgniter'daki bir adres defteri modülü, örneğin.

Modelleri çözüm 1: birlikte tüm ilgili yöntemler bunching (değil gerçek bir nesne değil, bir "paket")

class Contacts extends Model {

     function create_contact() {)
     function read_contact() {}
     function update_contact() {}
     function delete_contact() {}

     function add_contact_to_group() {}
     function delete_contact_from_group() {}

     function create_group() {}
     function read_group() {}
     function update_group() {}
     function delete_group() {}

}

Modeller çözüm 2: OOP yolu (dosya başına bir sınıf)

class Contact extends Model {
     private $name = '';
     private $id = '';

     function create_contact() {)
     function read_contact() {}
     function update_contact() {}
     function delete_contact() {}

}

class ContactGroup extends Model {
     private $name = '';
     private $id = '';

     function add_contact_to_group() {}
     function delete_contact_from_group() {}

     function create_group() {}
     function read_group() {}
     function update_group() {}
     function delete_group() {}

}

i modeller oluşturmak istediğinizde düşünmek nasıl bilmiyorum. ve yukarıdaki örnek bir Adres defteri oluşturmak için benim gerçek görevleri vardır. Meli ben sadece demet tüm işlevleri, birlikte bir sınıf. Daha sonra sınıf, farklı mantık (iletişim ve grubu) içerir, bu yüzden onların hiç biri için özel olan özellikleri tutamaz.

OOP göre çözelti, 2 çalışır. ama ben böyle bir bölünmesini yapmak gerekir neden bilmiyorum. ne faydaları örneğin bir kişi nesnesi sahip olacaktır. Onun kesinlikle değil bir User nesnesi, yani niçin kendi devlet (özellikleri ve yöntemleri) ile "canlı" Bir Kişiyi. Ben böyle düşünüyorum eğilimindedir Neden: bir şey bir devlete ihtiyacı varsa yöntemler durumuna göre devleti ya da başka şeyler etkileyebilir ki, sonra ben bir OOP sınıf oluşturmak.

böylece modelleri de "durum bilgisi" olmalıdır? hiçbir devlet gerekiyorsa, neden ben OOP desenine göre bunu oluşturmanız gerekir. sonra ben "paket" çözüm gibi birlikte sadece demet hepsini yapamadım.

OOP / MVC ile deneyimli çocuklar, bir bu çok somut görevi burada düşünmek gerekir nasıl bir ışık tutacak lütfen (ve genel olarak bir model oluştururken)

EDIT: MVC Kontrolörleri düşünmek geliyor. Bu "paket" çözüme göre oluşturulur. Bu beni düşündürüyor ...

3 Cevap

should every model be a database/table/row (solution 2)?

No sebat onun yöntemine bir model tanımını kravat etmeyin. Basit uygulamalar için bir veritabanı satır nesneden bir model uzatabilir rağmen, en azından zihinsel olarak ayrılmış tutmalı.

Zorunluluktan onlar devleti var ve bu yüzden Modelleri, sizin etki sadece varlıkların temsilleri vardır. Bir İletişim modeli hakkında konuşmak nerede, gerçekten nesne veri deposundan modelinizi almak, yani bir eşleyiciden veya ağ geçidi bahsediyoruz. Active Record pek çok ad hoc uygulamaları bu konuda suları bulandırdı ki talihsiz.

Haritacıları statik fonksiyonları bir koleksiyon olarak veya bir nesne olarak uygulanabilir - (örneğin birim test için alaycı gibi) herhangi bir nedenle davranışını genişletmek veya değiştirmek istiyorsanız, ancak, koleksiyon daha az esnektir.

Model kendisini sadece bir veri toplama olacak, ya appropriate ayarlayıcıları ve alıcılar (Sadece her değişken ya öldürürsün de bir get / set işlevi çifti tanımlamak etmeyiniz tercihen genel özelliklerine veya gibi saklanan gerekir sadece veri üzerinde çalışan diğer yöntemlerle birlikte) halk onları bırakın. Bu kavramı yok, ya da, veri deposu üzerinde bağımlılık gerekir. Onun arabirimi aracılığıyla modeli örneğini ve başlatmak için eşleyiciye sorumluluğundadır. Bu yapmak size nasıl oluşturabilirsiniz esneklik göze ve modelleri kurtaracak. Sen veritabanından bunu yapabilirsiniz, bir XML dosyası, in-kod, bir tefrika akışından tüm farklı eşleştiricisini ikame edilmesi suretiyle, gerçekten tekne yüzer ne olursa olsun, ağ üzerinden gönderilen ve model tamamen habersiz kalır.

Bir best way varsa ben bilmiyorum, ama ben bunu bir şekilde paylaşacağız ...

Ben bir tablo geçidi, sözgelimi var Kişiler ile başa çıkmak için tüm SQL içeren ContactTableGateway. Ben tek bir yerde olmak tüm sql gibi.

class ContactTableGateway extends Model {

    function saveContact( Contact $contact )
    function getContact ( $contact_id )
    function createContact ( Contact $contact )

}

Sonra ben temelde sadece alıcı ve ayarlayıcıları (veya ortak özelliklerini) olan bir kişi sınıf var. Bu sınıfın nesneleri oluşturmak / kaydetmek için tablo ağ geçidi için argüman olarak kullanılmaktadır

class Contact extends Model {

    function getName()
    function getAddress()
    function getEmail()
    ....

}

İşte basitleştirilmiş bir örnek

if ( isset( $_POST ) ) {

    // some validation here
    $contact = new Contact;
    $contact->name = $_POST['name'];
    $contact->email = $_POST['email']
    $contactTableGateway = new ContactTableGateway;

    if ( $contactTableGateway->createContact( $contact ) ) {
        echo "YAY";
    }
}

Ben daha çok moleküler / modüler bulunuyor, bu nedenle, daha anlaşılır, esnek ve genişletilebilir (OOP etki) gibi 2. Çözüm üstün olduğunu düşünüyorum. Ayrıca hiçbir temas grubu işlevselliği tersi gereklidir ve zaman sadece İletişim sınıfı yüklemek zorunda izin verebilir gibi kolay fazla kaynak bulunuyor. Bu bölünme şeydir.

Modeller hiçbir devlet gerekiyorsa, o cepten / MVC geçerli değildir anlamına gelmez. Tablo modelleri kişinin tasarım hiçbir devlet olabilir ama biz statik yöntemler / üyeleri var neden olduğunu, yani, İletişim :: read ($ id).

etiketler