Zend_Db_Table_Abstract uzanan vs Zend Framework ORM-stili tablo veri ağ geçidi

3 Cevap php

Yılında Zend Framework Quickstart, Tablo Veri Ağ Geçidi desen Zend_Db_Table_Abstract uzatmak modellerden bir değişiklik olmamıştır.

Şahsen, ben bu model ile çok deneyim olmadı ve ben bu büyük olasılıkla eski yol yerine kullanıldı gerektiğini işitme tutmak.

A short example from the quickstart:

Old way:

class Default_Model_Guestbook extends Zend_Db_Table_Abstract
{
    protected $_name = 'tablename';

    // do stuff
}

New way:

// The actual model
class Default_Model_Guestbook
{
    protected $_comment;
    protected $_created;
    protected $_poster;
    // list continues with all columns
}

// Dbtable for this model
class Default_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract
{
    /** Table name */
    protected $_name    = 'guestbook';
}

// Mapper 
class Default_Model_GuestbookMapper
{
    public function save($model);
    public function find($id, $model);
    public function fetchAll();
}

Programlama bu tarzı ile benim eksik deneyim, ben zor bu ikinci yoldan gerçek yararlarını kavramak bulabilirsiniz; Ben bu yöntemi teoride kolay başka bir veritabanı platformuna geçiş yapmak gerekir mümkün olduğunca gerçek mantık, veritabanını ayıran anlıyorum. Ancak, gerçekten ben çalışıyorum herhangi bir proje üzerinde bu olay görmüyorum.

Orada neredeyse hiç şüphesiz ben bir şey bakan olduğumu, bu yüzden ben tavsiye duymak isteriz.

The question:

  • Could someone please explain to me why (or if) the latter is better practice?

  • Should I switch from the old way to the new way or are there still proper reasons for sticking with models that represent database tables?

Şimdiden teşekkürler.

3 Cevap

İşte bu iyi bir uygulama neden benim açıklama var:

Ben bu real parası sorunsuz veri kaynaklarını değiştirme yeteneği olduğunu düşünüyorum. Bir model veri gösterimi (değil bir ağ geçidi) olması gerektiği gibi uygulama içine soyutlama ek bir katman ekleyerek, sizin modeller artık (benim görüşüme göre, vermemeliydim) bir veritabanı tablosunu temsil eder. Veritabanı erişim katmanı size daha fazla esneklik sağlayan modeli ile kapsüllü edilmelidir.

Örneğin, uygulama veri kaynağı / depolama olduğu gibi bir soap hizmet veya XML-RPC kullanmaya başlamak için gerekli söylüyorlar. Veri mapper yaklaşımı kullanarak, zaten mevcut modelleri ile çok (varsa) müdahalesi olmadan belirli bir veri katmanı arayüzleri eklemek için yerinde gerekli yapıya sahip olarak, ayrı bir avantajı da vardır.

Eğer olsa, bunu yapmak gerekir? Bu pragmatik bir soru. Şahsen, ben esnek ve aşağıdaki şey iyi uygulamalar (üzerinde anlaştılar) gelişmekte olduğumu huzuru var gibi. Ancak, sadece daha esnek bir uygulama oluşturma inşa etmek ve korumak için, gelecekte daha kolay projeler, ya şimdi ya da biraz zaman yapacak olmadığını biliyorum.

Benim için, ben sadece bir şey yapıyorum hissi gibi, ben en iyi uygulama olarak düşünün ve genellikle temettü öder.

Ben benzer bir teknede yaşıyorum ve ben bir şey eksik eminim.

Belki de soru revize edilmesi gereken yanıtları dayalı.

Ben size söz ZF 1.8 Hızlı Başlangıç ​​uygulaması, ziyaretçi defterine benzer veri eşleştiricisini kullanarak benim projeyi hayata ediyorum.

Ne endişe duyuyorum 50 artı tablolar ile, nasıl bir gereksiz kod ve çok sayıda dosyaları önlemek için ziyaretçi defteri uygulaması örnek adapte olmasıdır. Her tablo oldukça biraz masanın başına 3 dosyalarıyla, ziyaretçi defterine o kadar uygulanan ise.

İkinci soru bir açık (örn. sınıf Default_Model_Guestbook) modelindeki her tablo için alan adlarını tanımlamak zorunda olacağını uygulaması ile, olduğunu. Bu etrafında bir yolu var mı, ve hatta bu yüzden, parası parçası yapmak zorunda değil, değil mi?

Birisi projeye gelince, o (model arabirimi tarafından kaynağı / kontrol ederek) veritabanı yapısının bilgisi olmadan kolayca yeni bir örneğini oluşturmak anlamına gelir - Eğer $insert = new Model_Guestbook($param1, $param2, $param3); yapabilirim çünkü yararlıdır. Bu sadece bu yöntem sunuyor faydalarından biridir :)

etiketler