Yapılandırma dosyam için XML dışında bir şey kullanılması önerilir mi?

Tasarladığım küçük bir araca sahibim, bu da bir çeşit yapılandırma dosyası gerektiriyor. Benim durumumdaki konfigürasyon dosyası gerçekten bir veritabanından oluşuyor, ancak hafif olması gerekiyor ve gerekirse son kullanıcı tarafından kolayca düzenlenebilir olması gerekiyor. Bununla birlikte, içinde birçok şey içerecektir. (belirli faktörlere bağlı olarak, 1Mb veya daha fazla olabilir)

SQLite veya benzeri bir şey kullanmayı denemek yerine, düz ol 'metni kullanmaya karar verdim. Ancak, metin kullanarak, aynı zamanda çeşitli biçimlerle de uğraşmak zorundayım. Şimdiye kadar seçeneklerim

  • xml
  • JSON
  • Özel biçim

Dosyamdaki veriler, anahtar/değer türündeki şeylerin çoğundan oluşan oldukça basittir. Bu yüzden, özel bir format o kadar zor olmazdı ... ama bunun için destek yazma konusunda endişelenmek istemem. Yapılandırma dosyaları için kullanılan JSON'u hiç görmedim. Ve xml dosya boyutunu şişirirdi. (Ayrıca genel olarak bir xml sevmediğim var).

Bu durumda ne yapmalıyım?

Dikkate alınacak faktörler:

  • This configuration file can be uploaded to a web service(so size matters)
  • Users must be able to edit it by hand if necessary(ease of editing and reading matters)
  • Must be able to generate and process automatically (speed doesn't matter a lot, but not excessively slow)
  • The "keys" and "values" are plain strings, but must be escaped because they can contain anything. (unicode and escaping has to work easily)
  • Multiple configuration files. Basically, each config file is tied to one "project"
8
@MattDavey "Genel" bir yapılandırmadan bahsetmiyorum, proje başına bir şey yapmayı tercih ederim. (Visual Studio Çözümleri veya benzeri bir şeye benzer)
katma yazar Nidonocu, kaynak
@sawa aslında YAML'ı hiç duymadım. Oldukça ilginç görünüyor
katma yazar Nidonocu, kaynak
@GrandmasterB bir konsol uygulamasını bir web uygulamasıyla bir araya getirir. Konsol uygulaması her çalıştırmada kullanır, web uygulaması sık sık yüklenir, ancak sorgulamayı ve aramayı kolaylaştırmak için yalnızca bir kez yüklemeyi ve sonra MongoDB'ye doldurmayı planladım.
katma yazar Nidonocu, kaynak
INI dosyaları ne olacak? Hem Windows hem de UNIX benzeri sistemlerde uygulamaları yapılandırmanın en yaygın yoludur.
katma yazar slashnick, kaynak
Config dosyası ne sıklıkla okunur? Sadece program/servis başlangıcında? Yoksa bu, her web sayfası yüklendiğinde okunan bir şey mi? Performans ihtiyacı, seçiminizi biçiminde etkileyecektir.
katma yazar Daniel McPherson, kaynak
.NET yapılandırması olgun ve iyi anlaşılmış bir işlemdir ... neden tekeri yeniden icat ettin?
katma yazar MattDavey, kaynak
@Earlz ve gerekirse son kullanıcı kolayca düzenlenebilir bulmalıdır. Bununla birlikte, içinde birçok şey içerecektir. (belirli faktörlere bağlı olarak, 1Mb veya daha fazla olabilir) . Pastanı yiyip yiyemezsin. 1 MB dosyalar tanımı gereği kolay düzenlenemez. Ya bir veritabanı (küçük olsa bile) ve sonra SQL-lite iyi bir seçenektir veya bir config dosyasıdır (1MB'lık config'a sahip olmamalısınız).
katma yazar xirt, kaynak
Neden YAML'ı düşünmüyorsun? Bence YAML en uygunudur.
katma yazar Mike W., kaynak

7 cevap

Sanırım YAML , davanıza en uygun olanı. Anladığım kadarıyla, YAML elle düzenlenmesi gereken yapılandırma dosyaları için fiili standart formattır. Birçok programlama dilinde YAML okumak ve/veya yazmak için bir kütüphane bulunur. JSON, YAML ile yakından ilgilidir, ancak YAML'den yazmaktan biraz daha az kolaydır ve web sunucusu ile istemci programı arasındaki iletişimde daha fazla kullanılır.

10
katma
De facto kimin arasında?
katma yazar djn, kaynak

Gereksinimlerinize bakıp XML'den hoşlanmadığınızı gördükten sonra, JSON'a gitmenizi öneririm. Sadece xml ve JSON ile ilgilendiğimi itiraf etmeliyim, bu yüzden dışarıdaki diğer ortak yapılandırma biçimleri için konuşamam.

JSON yazması gerçekten kolay ve doğru biçimlendirilmişse okunması kolay. Google sadece araçlarında konfigürasyon kullanımı için JSON'U SEVİYOR. Ayrıca, JavaScript onu doğal olarak nesnelere dönüştürebilir.

7
katma

JSON kullanıyorsanız, insanlar farklı şeyler denemek için yapılandırma bitlerini yorumlayamazlar. Benim için bu bir anlaşma kırıcı.

Ayrıca, kullanıcıların özelleştirmesi için güzel bir şekilde yorumlanmış bir örnek yapılandırma dosyası sağlayamazsınız.

XML standarttır ve bir şema sağlayabilirseniz, kullanıcılarınız size teşekkür eder.

3
katma
+1 JSON ile olan kötü deneyimlerinden bahsetmek üzereydim. Geçerli bir "yapılandırma" formatı değil: yorum yok, gerçekten okunaklı değil, karartılmış virgüllerin listelerde bırakılması kolay, config nesneleri arasındaki referansları işlemez. YAML veya xml gerçek seçeneklerdir.
katma yazar ec2011, kaynak

Bir "properties" dosyası, formatın kendisi anahtar/değer olduğundan anahtar/değer için iyidir. Anahtar/değer başına sadece 1 satır var. Satırdaki ilk = işareti anahtarı ve değeri böler.

Tek biçimlendirme "=" ayırıcı ve yeni satır karakteri olduğundan, eşdeğer bir xml dosyasından daha küçük olacaktır. Bir xml dosyasında biçimlendirme, içeriğin kendisi kadar fazla yer alabilir. Kelimenin tam anlamıyla 1 MB ve 2 MB yükleme arasındaki fark anlamına gelebilir. Sıkıştırma yardımcı olur, ancak küçük başlarsanız hala önde olursunuz.

Mevcut kitaplıklar özellik dosyalarına erişimi yönetebilir. Fakat birkaç dakika içinde kendi başınıza yapabileceğiniz çok önemsiz. Bir saat içinde çan ve ıslık çalar.

IP=11.22.33.44
BuildNumber=5.02.004
MaxFrameRate=50
1
katma

Burada zaten bazı iyi cevaplar. Ama ayakkabının içinde olsaydım, XML'i tahtaya atmadan önce, şu noktaları göz önüne alırdım:

  • xml çok .NET çerçevesi ve üçüncü taraf araçları tarafından iyi desteklenir, JSON için bir üçüncü taraf kitaplığı seçmeniz ve tüm gereksinimlerinizi karşılayıp karşılamadığını görmeniz gerekir.

  • yalnızca birkaç istisnai durum için el ile düzenlemeye ihtiyacınız varsa, xml muhtemelen ihtiyaçlarınızı karşılayacaktır. Yapılması gereken çok sayıda düzenleme varsa ve yapılandırma seçenek listenizin belirli bir karmaşıklığı varsa, kullanıcılarınız büyük olasılıkla bir tür iletişim tabanlı seçenek/yapılandırma uygulamasına ihtiyaç duyar - bu, temel xml biçiminin 100 olması önemli değil % kullanıcı dostu. Böyle bir şey yazmak istemiyorsanız, en azından kullanıcılarınıza bir tür xml editörü önerebilirsiniz. xml not defteri veya Notepad ++ için xml araçları birçok insan için işe yarar.

  • Son kullanıcılarınızın, daha önce JSON'u görme şansından daha önce bir tür xml görmüş olma ihtimalinin daha yüksek olduğunu tahmin ediyorum - bu durum onları gerçekten kavramalarını biraz daha kolaylaştıracak. yapmak zorunda)

  • Boyut, bir web servisine veri yüklemek için gerçekten sorun çıkarırsa, veri sıkıştırmayı kullanmayı düşünün

Aslında, bu noktaları düşünüyorsanız ve yine de xml kullanmak istemiyorsanız, bunun yerine JSON ile gidin. xml veya JSON kullanmak, size standart olarak kaçan dizeler, daha sonra yapılandırma yapınızı genişletmenin standart yolları, standart yorum ekleme yolları ve bu biçimleri okumak ve yazmak için hazır lib'ler sunar - tekerleği yeniden icat etmeye gerek yoktur Herhangi bir "özel format".

1
katma
XML ile ilgili en büyük sorun çok ayrıntılı. 20 karakterlik 2000 dizgim varsa, 40000 bayt veya 40K olur. Şimdi xml ekleyin ve her şeyin karşısına xml etiketlerinin yükünü gerçekten ekleyebilirsiniz. ve , dize başına 21 karakter daha ekler. Bu, büyüklüğün önemli olduğu bu özel senaryoda XML'le olan sorunumdur, ancak ikili ya da bir şeyin gerekli olduğu yerlerde çok önemli değildir.
katma yazar Nidonocu, kaynak
@Earlz: yukarıda yazdığım gibi, eğer büyüklük gerçekten önemliyse, neden veri sıkıştırmayı denemiyorsunuz (örneğin, icsharpcode.net/OpenSource/SharpZipLib/Default.aspx )? Ve dürüst olmak gerekirse, dosyalar 40K veya 80K'ya sahipse senaryonuzda kesinlikle önemli olduğundan emin misiniz?
katma yazar Peter LeFanu Lumsdaine, kaynak

Konfigürasyon dosyalarına gelince, kesinlikle "1Mb veya daha fazlası" büyük bir tarafta ve karakterlerden kaçma ve çok sayıda eşleşen tırnak işareti bulundurma ihtiyacı insanlarda iyi görünmüyor. Bu nedenle, insanlar tarafından muhafaza edilmesi gereken büyük konfigürasyon dosyaları için kesinlikle özel bir format tanımlamayı ve özel bir ayrıştırıcı oluşturmayı düşünmelisiniz. İşte, insanların xml yazmak zorunda kaldıkları hakkında bir makale: < em> İnsanların XML'i kırması gerekmemelidir .

Ayrıştırıcılar ve ayrıştırma jeneratörleri bebeklik çağındayken, özel bir dil oluşturmanın çok karmaşık olduğunu söyleyerek özel bir dil oluşturmama için dava açabilirsiniz. Şimdi mükemmel ve çok basit ayrıştırma jeneratörleri olgunlaştı, artık mazeret yok: xml tabanlı bir dil için bir ayrıştırıcı oluşturmanın ne kadar zaman alacağı konusunda birkaç saat içinde özel bir ayrıştırıcı oluşturabilirsiniz. sup> * .

Here is a small tutorial explaining the process of building a custom parser with ANTLR. It is in Java, but ANTLR supports C# as well.


* Unless you go for deserialization-based conversion from XML, in which case building an XML-based parser would take less time, but your classes would need to have a "shape" that closely resembles your XML.
1
katma

JSON, esnekliği, program dışında okuma ve düzenleme kolaylığı, ayrıştırma kitaplıklarının desteklenmesi için geniş kullanılabilirliği için iyi bir seçimdir. Hiyerarşiyi destekler, basitçe verileri sırayla kaydetmeyen bir dosyanın basit ileri/geri uyumluluğunu sağlar. Ayrıca, Java sınıfları ve dosya verileri arasında dönüştürme yapmak ve daha sonra diğer yöntemlerle geri dönüş yapmak için kolay tekniklere sahip olduğunu düşünüyorum. Bir çok insan bu formatı biliyor ve kodluyor ve format gelecekte çalışmanız gereken diğer programlar için önemlidir.

Birçok sistem .ini biçimine dayanıyordu ve sıfırdan bir çözümleyici yazıyorsanız ayrıştırmaları oldukça kolaydır.

CSV kodlamak için hızlı olabilir ve çok az ek yük ile çalışır, ancak esneklik, ileri/geri uyumluluk sorunları var.

Kayıt defterini kullanmak, Windows'ta yaygın bir uygulamadır.

Çerezleri kullanmak web geliştirme için yaygındır.

Bir yardımcı program işlevi için komut satırı seçeneklerinizle eşleşen serbest biçimli metni kullanın, onu okuyun ve bir argv string dizisi yapın.

0
katma