my_config.ini مقابل my_config.php

Question

في العمل نستخدم .ini إلى مجموعة المتغيرات قبل استدعاء بقية إطار (أعتقد أنه يذهب

function getConfigVars(){
    //read my_config.ini file
    ....
    //call framework
}

وأنا دائما أتساءل إذا كان هناك فائدة هذه الطريقة.

يبدو لي أن لديك ثم كتابة قواعد الوصول إلى منع الناس من يبحث في ذلك من الويب و php وقد تحليل وفهم ذلك.

لذا, لماذا استخدام my_config.ini بدلا من my_config.php?انها ليست مثل أي شخص يجب أن يكون لمسها بعد ذلك يتم إعداد و يبدو أكثر ملاءمة لمجرد استدعاء المتغيرات تكون قادرة على IDE الخاص بك السيارات كاملة النص أينما كنت باستخدام ini المتغيرات / تحليل الأخطاء.

Answer 1

الإطار زند يحتوي على يوزع التكوين الذي يوزع الملفات التي هي مكتوبة في شكل رسائل كتبها هذا المؤلف (<أ href ل = "http://framework.zend.com/manual/en/zend.config.adapters.ini.html" يختلط = "noreferrer"> Zend_Config_Ini )، فإنه يبدو وكأنه هذا هو ما تستخدمه.

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

<اقتباس فقرة>   

وتنسيق INI المتخصصة لتقديم كل القدرة على الحصول على تسلسل هرمي من مفاتيح بيانات التكوين والميراث بين أقسام بيانات التكوين. ويدعم الهرمية بيانات التكوين عن طريق فصل مفاتيح مع نقطة أو حرف نقطة (.). قسم قد تمتد أو يرث من قسم آخر عن طريق اتباع اسم المقطع مع حرف نقطتين (:) واسم القسم من التي يتم توارث البيانات.

Zend_Config_Ini الصفحة.

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

وبالتأكيد، فإن هذا سيكون ممكنا مع برنامج نصي PHP، ولكن ذلك يتطلب المزيد من إعراب المتغيرات التكوين المختلفة وكذلك تفعل إذا / ثم يتحقق، في حين باستخدام parse_ini_file () يفعل كل هذا بالنسبة لك تلقائيا.

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

مثال من موقع على شبكة الانترنت وأنا أعمل حاليا على:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts"
resources.db.adapter       = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users.db"

resources.view[] =

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-testing.db"

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-dev.db

وهذا يجعل من السهل للغاية أن يكون مجموعات بيانات متعددة لمختلف البيئات التي يمكن تشغيل التعليمات البرمجية.

Answer 2

وبالنسبة لأولئك الذين يأتون إلى هذه المسألة لأنها تريد أن تعرف ما إذا كان هناك أي اختلافات في الأداء بين باستخدام ملف INI التي يجب تحليلها وملف PHP التي يتم تضمينها ببساطة (ويمكن أن يكون مؤقتا بواسطة PHP): نعم، هناك اختلافات لكنها صغيرة بحيث لا يهم حقا.

وبلدي السيناريو الرئيسى هو ملف config.ini مع 20 أزواج مفتاح / قيمة وملف config.php بنفس أزواج 20 مفتاح / قيمة كما هو مكتوب يعرف. PHP الإصدار 5.4.9 على أوبونتو لينكس 13.04.

key1 = value1
...
key20 = value20

ومقابل.

<?php
define("key1", "value1");
...
define("key2", "value20");

واثنين من مخطوطات الاختبار بما في ذلك التكوينات:

<?php
$CONF = parse_ini_file("config.ini");

ومقابل.

<?php
require_once "config.php";

وأنا اختبار الأداء مع ab -c 25 -n 10000.

والنتيجة دون مخبأ PHP:

ini: Requests per second:    2660.89 [#/sec] (mean)
php: Requests per second:    2642.28 [#/sec] (mean)

والنتيجة مع APC PHP مخبأ:

ini: Requests per second:    3294.47 [#/sec] (mean)
php: Requests per second:    3307.89 [#/sec] (mean)

وركضت الاختبارات عدة مرات، وبطبيعة الحال الأرقام تختلف في كل مرة ولكن التوافق هو: config.ini هو أسرع قليلا عند استخدام أي مخبأ PHP، config.php هو أسرع قليلا عند استخدام مخبأ PHP. ولكن الفرق هو صغير جدا أن القرار لا ينبغي أن يقوم على أساس الأداء.

Answer 3

سؤالك يثير نقطة عادلة ، للتأكد.

بضع نقاط لصالح .ini الملفات:

• استخدام الملف مع لغة أخرى.إذا كنت من أي وقت مضى يريد أن يكون Perl, Python, Ruby, الخ.السيناريو هو من السهل خاصة مع أن اللغة المطلوبة للوصول إلى إعدادات المشروع سوف يكون من الحظ إذا كنت تخزين الإعدادات في ملف PHP.

• تحرير الإنسان من البيانات.على الرغم من أنك رفضت ذلك في سؤالك النوايا أو لا فمن المرجح جدا أن شخص ما قد ينتهي بدس هناك و قد لا يكون الفنية الفردية.INI الشكل هو أقل كثيرا مخيفة من رمز PHP, حتى لو كان مجرد حفنة من الإعلانات المتغيرة

• تحديث إعدادات.أعتقد أنه أسهل بكثير من إنشاء جديد INI بدلا من كتابة ملف PHP.هذا هو شخصي جدا ، ومع ذلك ، ولكن من الجدير بالذكر.

• العلاقة بين تحديد المتغيرات.فمن السهل إلى حد ما/بديهية لإعطاء الخاص بك إعدادات التسلسل الهرمي مع INI.في حين أن هذا قد يكون من الممكن أيضا مع PHP أنها ليست نظيفة و يمكن الحصول على القبيحة إذا كنت تحاول أن تفعل متداخلة صفائف النقابي إلى مخزن المعلومات.

بالإضافة إلى تلك تدق على INI من "الحاجة إلى حماية ضد الوصول إلى شبكة الإنترنت" ليست ذات الصلة في معظم سيناريوهات حيث أن معظم مشاريع PHP (على الأقل تلك التي أنا جزء من) عقد قدرا كبيرا من التعليمات البرمجية من المجلد الجذر و الإعدادات عادة الذهاب إلى هناك.

Answer 4

وإضافة إلى أنه قد يكون من الأسهل لغير مبرمج لتعديل متغيرات التكوين ... إذا كان هذا ضروريا في مكان عملك.

ولقد اكتشفت وضع دقيق لل<?php و?> يستطيع ان يمنعها من الظهور، في حين أن parse_ini_file () سوف لا يزال الحصول على البيانات ذات الصلة من ملف.

وأفضل طريقة لضمان الحصول عليها رغم ذلك، هو وضعه فوق docroot، ومنع الوصول إلى .INI * في إعداد الخادم الخاص بك.