PHP Zend Framework - Zend_Config ve küresel devlet

3 Cevap php

Ben basit bir sabit dosyasını kullanarak karşı Zend_Config_Ini yararları değerlendirilmesi sürecinde yaşıyorum.

örneğin -

define('DB_HOST',localhost);

//versus

$config = new Zend_Config_Ini('/path/to/config.ini', 'staging');
echo $config->database->params->host;   // prints "dev.example.com"

Tek şey $ config dünya çapında erişilebilir olmasıdır. Öyleyse her zaman başlatmak zorunda kalmadan, uygulama kullanım için saklamak için Zend_Registry kullanmanız gerekir.

Bu benim bir şey eksik veya Zend_Config + Zend_Registry bir uygulama büyüdükçe uzun vadede daha iyi bir tekniktir ediyorum .... ihtiyaç daha fazla karmaşıklık eklemek gibi görünüyor?

3 Cevap

Bir config ile Kayıt kullanmanın ana avantajı küresel ad kirletici kaçınmaktır. Say, bir üçüncü taraf lib ve app ve lib arasında hem sabit DB_HOST tanımlamak istiyorum. Hiçbir iyi.

Buna ek olarak, Zend Framework fabrikalarının birçok örneklerini oluşturmak için yapılandırma nesne kullanmaktadır. Zend_Db Bu iyi bir örnektir. Sadece bunu $this->database geçmek ve o sizin adaptör örneğini gerekenleri alacaktır.

Ayrıca, örneğin, özel işlevselliği ile kayıt uzatabilirsiniz böyle bulucu yöntemler veya şeyler. Fowler tarafından pattern description edin.

Bir güzel avantajı Zend_Config Eğer bir "PHP kaynak kod dosyasının" bağlı kalmamasıdır; . Sadece bir ini dosyası yapacak - ve bazı ini dosyası yerine bir PHP birini değiştirerek tercih ederim..

. Ve bu programlama bir ini / XML dosyasını değiştirmek için kolay - bunu sınıfları / işlevleri vardır!

Ile ini dosyaları ve Zend_Config, sen de güzel functionnalities zaten sağladı.; Örneğin, bölümler arasında kalıtım (ie, you can have a "generic" section, and "staging" and "production" that overwrite some values)


A thing that can be insteresting about Zend_Config, too, is consitency : Zend Framework, with Zend_Application, already supposes you'll have one configuration file ; so, why not a second one ? Or even re-use the first one ?

Ve işe veya Zend_Config bir örneği ile yapılandırılabilir Framework çeşitli sınıflar ile aynı şey; Zaten bir, aniden daha kolay hale gelir varsa ;-)


If I had to choose between a PHP file with defines and a .ini file, for things that are configurable, I would probably go with the .ini file (And Zend_Config + Zend_Registry when needed).

Evet, yapılandırma için Zend yaptırıma yöntemini kullanarak, doğru konum küresel sabitleri bir dizi tanımlayarak daha karmaşıktır. Alacağınız avantajları

No Global Namespace Collisions

Hiç genel sabitler uygulama geneli temsil sahip başka bir proje ile uygulama entegre etmek için gerekirse sorunlara neden olabilir. Başka bir proje isimli bir sabit vardır şansı nedir DB_HOST? Nasıl hibrid sistemi kullanıyor geliştirici entegre uygulama vs uygulamanız için yapılandırma hangi sabitleri söyleyebilir?

Building on the Work of Others

Yani, bütün yapılandırma değerleri ile tek bir dosya var. Nasıl farklı ortamlarda içine dağıtmak için gidiyorsun? (Üretim, hazırlama, vb) Şansını bir çözüm ile gelip akıllı bir insansın, ama nasıl başka bir geliştirici bu çözüm nasıl çalıştığını bilmek gidiyor projeye geliyor? Nasıl uygulama diğer modüller global config dosyasını okumaya nasıl olacak?

Zend_Config zaten sorunların çoğu "çözüldü" oldu. Biraz daha karmaşıklık ve soyutlama üzerine alarak önünüzde ileriye bilinen bir yolunu almak ve uygulama sorunlarını çözme yerine Yet Another Yapılandırma Sistemi icat ve desteklenmesi üzerinde daha fazla vakit geçirebilirsiniz.

etiketler