تطبيق ملفات التكوين [مغلقة]

https://stackoverflow.com/questions/12144

08-06-2019
|

سؤال

حسنا, إذا كنت لا تريد أن تبدأ المقدسة الحرب هنا ، ولكن نحن في عملية محاولة توحيد طريقة التعامل مع التطبيق لدينا ملفات التكوين و نحن تكافح من أجل اتخاذ قرار بشأن النهج الأفضل أن تأخذ.في هذه اللحظة, كل تطبيق نوزع هو نفسه المخصص تكوين الملفات, سواء كان ملفات أملاك (ini نمط), XML أو JSON (الداخلية فقط في هذه اللحظة!).

لدينا أكثر من شفرة جافا في هذه اللحظة, لذا كنا نبحث في أباتشي العموم Config, ولكن لقد وجدت لها أن تكون تماما مطول.لقد بحثت أيضا في XMLBeans, ولكن يبدو أن الكثير من faffing حولها.أنا أيضا أشعر كما لو أنني يتم دفعها نحو XML كما شكل لكن العملاء والزملاء متخوفين من محاولة شيء آخر.أنا يمكن أن نفهم ذلك من وجهة نظر الزبون, الجميع سمع من XML ، ولكن في نهاية اليوم, لا ينبغي أن يكون استخدام الأداة المناسبة لهذا المنصب ؟

ما صيغ و المكتبات الأشخاص الذين يستخدمون في نظم الإنتاج في هذه الأيام ، هو أي شخص آخر يحاول تجنب زاوية قوس الضرائب?

تحرير: حقا يجب أن يكون عبر منصة الحل:لينكس, ويندوز, Solaris.... الخواختيار المكتبة تستخدم واجهة مع ملفات التكوين هو بنفس أهمية اختيار الشكل.

المحلول

XML XML XML XML.نحن نتحدث ملفات التكوين هنا.لا يوجد "زاوية قوس الضرائب" إذا كنت لا التسلسلية الكائنات في الأداء مكثفة الوضع.

ملفات التكوين يجب أن يكون الإنسان للقراءة الإنسان مفهومة ، بالإضافة إلى آلة قابل للقراءة.XML هو حلا وسطا جيدا بين البلدين.

إذا كان متجر الناس التي تخاف من أن فتية جديدة تقنية XML ، أشعر سيئة بالنسبة لك.

نصائح أخرى

YAML ، لسبب بسيط هو أن يجعل جدا للقراءة ملفات التكوين مقارنة مع XML.

XML:

<user id="babooey" on="cpu1">
    <firstname>Bob</firstname>
    <lastname>Abooey</lastname>
    <department>adv</department>
    <cell>555-1212</cell>
    <address password="xxxx">ahunter@example1.com</address>
    <address password="xxxx">babooey@example2.com</address>
</user>

YAML:

    babooey:
        computer : cpu1
        firstname: Bob
        lastname: Abooey
        cell: 555-1212
        addresses:
            - address: babooey@example1.com
              password: xxxx
            - address: babooey@example2.com
              password: xxxx

أمثلة أخذت من هذه الصفحة: http://www.kuro5hin.org/story/2004/10/29/14225/062

الأولى:هذا هو حقا كبيرة مناقشة المسألة ليست سريعة س+A.

بلدي المفضل الآن هو ببساطة تشمل لوا, لأن

أنا يمكن أن تسمح أشياء مثل العرض=الارتفاع*(1+1/3)
أنا يمكن أن تجعل مخصصة الوظائف المتاحة
لا يمكن أن تمنع أي شيء آخر.(من المستحيل ، على سبيل المثال ، بيثون (بما في ذلك المخللات.))
سوف ربما تريد لغة البرمجة في مكان آخر في المشروع على أي حال.

خيار آخر ، إذا كان هناك الكثير من البيانات هو استخدام sqlite3, لأنهم الحق في المطالبة

الصغيرة.
سريع.
موثوق بها.

اختيار أي ثلاثة.

الذي أود أن أضيف:

النسخ الاحتياطي هي المفاجئة.(مجرد نسخ الملف db.)
من السهل التبديل إلى آخر db, ODBC, أيا كان.(مما هو عليه من قبيح ملف)

ولكن مرة أخرى, هذا هو أكبر مشكلة."كبير" الإجابة على هذا ربما ينطوي على نوع من مصفوفة الميزة أو قائمة من الحالات مثل:

كمية البيانات أو قصيرة وقت التشغيل

على كميات كبيرة من البيانات قد تحتاج كفاءة التخزين ، مثل db.
على المديين القصير (غالبا) ، قد تريد شيئا أن كنت لا تحتاج إلى القيام بالكثير من تحليل عن النظر في شيء التي يمكن mmap:اد في مباشرة.

ماذا التكوين تتصل ؟

المضيف:
- أنا أحب YAML في /الخ.أن ل reimplemented في ويندوز ؟
المستخدم:
- هل تسمح للمستخدمين تحرير التكوين مع النص المحرر ؟
- يجب أن يكون مركزي يمكن التحكم فيها ؟ التسجيل / gconf / عن بعد db ؟
- قد يكون للمستخدم عدة مختلفة لمحات?
المشروع:
- ملف(ق) في مشروع الدليل ؟ (التحكم في الإصدار عادة ما يتبع هذا النموذج...)

تعقيد

هناك فقط عدد قليل من شقة القيم ؟ النظر في YAML.
هو البيانات المتداخلة ، أو تعتمد في بعض الطريق ؟ (هذا هو المكان الذي تحصل عليه للاهتمام.)
قد يكون من المرغوب فيه ميزة تسمح بعض شكل من أشكال البرمجة?
قوالب يمكن أن ينظر إليها على أنها نوع من ملفات التكوين..

دون بدء الحرب المقدسة مشاعر 'زاوية قوس الضرائب' آخر هو منطقة واحدة حيث كنت مجورلي نختلف مع جيف.لا يوجد شيء خاطئ مع XML, معقولة الإنسان للقراءة (بقدر YAML أو سلمان أو INI الملفات) ولكن تذكر القصد من ذلك هو أن تقرأ من قبل الآلات.معظم اللغات/إطار المجموعات تأتي مع محلل XML من نوع مجانا مما يجعل XML خيار جيد جدا.

أيضا, إذا كنت تستخدم جيد IDE مثل Visual Studio ، وإذا XML يأتي مع المخطط, يمكنك إعطاء المخطط أن VS بطريقة سحرية يمكنك الحصول على التحسس (يمكنك الحصول على واحد بالنسبة NHibernate على سبيل المثال).

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

هذا لا يزال يقول كل شيء بالنسبة لي حول XML و السبب في أنه لا يزال خيارا صالحا ملفات التكوين (من تيم براي):

"إذا كنت ترغب في توفير الأغراض العامة البيانات أن المتلقي قد ترغب في القيام به غير متوقعة غريب و أشياء مجنونة ، أو إذا كنت تريد أن تكون حقا بجنون العظمة و من الصعب إرضاءه حول i18n ، أو إذا ما كنت ترسل أكثر من وثيقة من البنية ، أو إذا كان ترتيب البيانات المسائل ، أو إذا كانت البيانات يحتمل أن تكون طويلة الأجل (كما هو الحال في أكثر من ثوان) XML هو الطريق للذهاب.كما يبدو لي أن الجمع بين XML و XPath يضرب بقعة الحلو صيغ البيانات التي تحتاج إلى أن تكون الموسعة;وهذا هو القول, فإنه من السهل جدا أن أكتب XML-معالجة التعليمات البرمجية التي لن تفشل في وجود تغييرات تنسيق الرسالة أن لا تلمس قطعة يهمك."

@الرجل

ولكن تطبيق التكوين ليس دائما فقط أزواج مفتاح/قيمة.ننظر شيئا مثل هر تكوين ما منافذ أنه يستمع.هنا مثال:

    <Connector port="80" maxHttpHeaderSize="8192"
           maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
           enableLookups="false" redirectPort="8443" acceptCount="100"
           connectionTimeout="20000" disableUploadTimeout="true" />


    <Connector port="8009" 
           enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

هل يمكن أن يكون أي عدد من الروابط.تحديد أكثر من ملف وأكثر موصلات موجودة.لا تحدد أي أكثر و لا وجود لها.لا توجد طريقة جيدة (imho) أن تفعل ذلك مع القديم عادي أزواج مفتاح/قيمة.

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

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

XML, JSON, INI.
لديهم كل نقاط القوة والضعف.
في سياق التطبيق ، أشعر أن طبقة تجريد هو الشيء المهم.
إذا كان يمكنك اختيار طريقة تنظيم البيانات هو الوسط بين الإنسان القراءة و كيف كنت ترغب في الوصول إلى/الملخص البيانات في التعليمات البرمجية أنت الذهبي.

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

و جميع اللغات على جميع المنصات تدعم XML من خلال بعض شائع جدا المكتبات.

@Herms

ما قصدته فعلا هو التمسك الطريقة الموصى بها برنامج مخزن التكوين القيم على أي منصة.

ما كنت غالبا ما تحصل على هذه الطرق الموصى بها هذه يجب/يمكن تعديلها.مثل القائمة التكوين في برنامج أو لوحة التكوين في نظام "بادئات" تطبيق (نظام الخدمات برامج ie).عدم السماح للمستخدمين النهائيين تعديلها مباشرة عن طريق RegEdit أو المفكرة...

لماذا ؟

المستخدمين (العملاء=) تستخدم برامجهم
نظام النسخ الاحتياطي يمكن أن الأفضل حفظ "آمنة الاجهزة" الخ

@ninesided

عن" الاختيار من مكتبة "،في محاولة الرابط (رابط ثابت) أي اختيار مكتبة لخفض خطر من الحصول على نسخة الصراع الحرب على المستخدمين النهائيين الآلات.

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

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

إذا كنت بحاجة إلى متداخلة البيانات و/أو القدرة على الاستعلام عن بيانات التكوين بعد تمهيد استخدام XML أو سكليتي.كلاهما جيد جدا لغات الاستعلام (XPATH و SQL) المهيكلة/المتداخلة البيانات.

إذا كان لديك بيانات التكوين للغاية تطبيع (مثلا ، 5 نموذج عادي) كنت أفضل حالا مع SQLite لأن SQL هو أفضل للتعامل مع درجة عالية من تطبيع البيانات.

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

تحقق من بلدي الصفحة لمزيد من المعلومات حول سكليتي.

بقدر ما أعرف, سجل ويندوز لم يعد يفضل طريقة تخزين التكوين إذا كنت تستخدم .صافي - معظم التطبيقات الآن الاستفادة من النظام.التكوين [1, 2].لأن هذا هو أيضا XML القائمة على ذلك يبدو أن كل شيء يسير في اتجاه باستخدام XML التكوين.

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

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

[1] النظام.تكوين مساحة - http://msdn.microsoft.com/en-us/library/system.configuration.aspx

[2] التطبيق باستخدام ملفات التهيئة .صافي http://www.developer.com/net/net/article.php/3396111

نحن نستخدم خصائص الملفات ببساطة لأن Java يدعم لهم أصلا.قبل شهرين رأيت أن SpringSource منصة التطبيق يستخدم سلمان إلى تكوين الخادم و تبدو مثيرة جدا للاهتمام.أنا مقارنة مختلف تكوين الرموز وجاء إلى استنتاج مفاده أن XML ويبدو أن الأنسب في الوقت الراهن.وقد لطيفة أدوات الدعم بدلا من منصة مستقلة.

Re:epatel تعليق

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

كما الفعلي السؤال أود أن أقول XML هو على الارجح موافق ، كما الكثير من الناس سوف تستخدم باستخدام هذا التكوين.طالما أنك تنظيم التكوين القيم في وسيلة سهلة لاستخدام الطريقة ثم "زاوية قوس الضرائب" لن يكون سيئا.

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

أعتقد أن الشيء الوحيد المهم هو اختيار الشكل الذي تفضله و يمكن التنقل بسرعة.XML و JSON هي بخير أشكال التكوينات و هي معتمدة على نطاق واسع--التنفيذ التقني ليس في جوهر القضية ، بدا لي.انها 100% عن ما يجعل مهمة التكوين الملفات أسهل بالنسبة لك.

لقد بدأت باستخدام جسون, لأنني أعمل قليلا جدا مع أنه نقل بيانات الشكل ، serializers تجعل من السهل تحميل في أي إطار التنمية.أجد سلمان أسهل في القراءة من XML ، مما يجعل التعامل مع خدمات متعددة ، بعضها باستخدام ملف التكوين أن يتم تعديل كثيرا كثيرا easer بالنسبة لي!

منصة ما تعمل ؟ أنصح محاولة استخدام المفضل/طريقة شائعة ذلك.

MacOSX - plists
Win32 - التسجيل (أو هل هناك واحدة جديدة هنا منذ فترة طويلة أنا وضعت على ذلك)
لينكس/يونكس ~/.apprc (اسم-قيمة ربما)

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow