سؤال

وأنا في عملية تقييم فوائد Zend_Config_Ini مقابل استخدام ملف ثابت بسيط.

ومنها مثلا. -

define('DB_HOST',localhost);

//versus

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

والشيء الوحيد هو أن $ التكوين لا يمكن الوصول إليها عالميا. لذلك فأنت بحاجة إلى استخدام Zend_Registry لتخزين لاستخدام التطبيق، دون الحاجة إلى الشروع في كل مرة.

وهذا يبدو لإضافة المزيد من التعقيد مما يجب .... أنا في عداد المفقودين شيء أو هو Zend_Config + Zend_Registry الاسلوب الذي هو أفضل على المدى الطويل كما ينمو التطبيق؟

هل كانت مفيدة؟

المحلول

ووالميزة الرئيسية لاستخدام التسجيل مع التكوين هو تجنب تلويث مساحة الاسم العالمي. يقول، كنت ترغب في تضمين ليب طرف ثالث، والتطبيق، وتحرر كلا تحديد DB_HOST المستمر. ليس جيدا.

وبالإضافة إلى ذلك، فإن العديد من المصانع في إطار زند استخدام الكائن التكوين لإنشاء مثيلات. Zend_Db هو خير مثال على ذلك. كنت مجرد تمريرها $this->database وسوف يستغرق ما يحتاج إلى مثيل محول.

ويمكنك أيضا تمديد التسجيل مع وظيفة مخصصة، على سبيل المثال طرق مكتشف أو أشياء من هذا القبيل. تحقق من وصف نمط التي كتبها فاولر.

نصائح أخرى

وهناك ميزة جميلة من Zend_Config هي أنك لا تعتمد على "PHP ملف التعليمات البرمجية المصدر". سوف مجرد ملف .ini تفعل - والبعض يفضل تعديل ملف .ini بدلا من PHP واحدة

وأنه من الأسهل لتعديل ملف .ini / XML برمجيا - هناك فئات / وظائف للقيام بذلك

ومع ملفات. ini وZend_Config، لديك أيضا functionnalities لطيفة قدمت بالفعل؛ على سبيل المثال، والميراث بين الأقسام (أي، هل يمكن أن يكون قسم "عام"، و "تنظيم" و "إنتاج" أن الكتابة بعض القيم)

و
والشيء الذي يمكن أن insteresting حول Zend_Config، أيضا، هو consitency: الإطار زند، مع Zend_Application، يفترض بالفعل سيكون لديك ملف التكوين واحد؛ لذلك، لماذا لا ثانية واحدة؟ أو حتى إعادة استخدام أول واحد؟

وانه نفس الشيء مع عدة أصناف من الإطار، والتي يمكن أن تعمل أو تهيئتها مع مثيل Zend_Config. إذا كان لديك بالفعل واحدة، يصبح فجأة أسهل؛ -)

و
إذا كان لي أن تختار بين ملف PHP مع يعرف وملف .ini، عن الأشياء التي هي شكلي، وأود أن تذهب على الأرجح مع ملف .ini <م> (وZend_Config + Zend_Registry عند الحاجة) .

نعم، كنت الصحيح، وذلك باستخدام طريقة زند عقوبات لتكوين أكثر تعقيدا من تحديد مجموعة من الثوابت العالمية. المزايا التي تحصل

لا العالمي النطاق التصادم

إذا احتجت لدمج التطبيق الخاص بك مع مشروع آخر، بعد أن الثوابت العالمية تمثل التكوين طلبك قد يسبب مشاكل. ما هي فرص ومشروع آخر يدعى ثابت DB_HOST؟ كيف يمكن لمطور الشخص الذي يستخدم نظام هجين بك تقول الذي الثوابت هي التكوين للتطبيق الخاص بك مقابل التطبيق المتكامل؟

بناء على العمل الغير

وهكذا، لديك ملف واحد مع كل القيم التكوين الخاص بك. كيف انت ذاهب لنشر ذلك في بيئات مختلفة؟ (الإنتاج، التدريج، الخ) وهناك احتمالات كنت الشخص الذكي الذي يمكن أن يأتي إلى حل، ولكن كيف هو مطور آخر قادم في المشروع سوف تعرف كيف يعمل هذا الحل؟ كيف يتم حدات أخرى في التطبيق الخاص بك الذهاب إلى معرفة كيفية قراءة التكوين العمومي؟

وZend_Config سبق "حل" العديد من المشاكل. عن طريق اتخاذ أكثر قليلا من التعقيد والتجريد مقدما تحصل على مسار معروف إلى الأمام، ويمكن أن تنفق المزيد من الوقت على حل مشاكل التطبيق الخاص بك بدلا من اختراع ودعم ولكن تكوين النظام آخر.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top