Pliki INI, rejestr lub pliki osobiste?

Chcę zapisać konfigurację mojego projektu, która obejmuje

1. Rozmiar ekranu
2. Pozycja ekranu
3. Ścieżki folderów
4. Ustawienia użytkowników i tak dalej.

Standardowe miejsca, w których można je zapisać, to wartości konfiguracji:

1. Rejestr
2. Pliki INI
3. Pliki osobiste (jak * .cfg)

Jak wybierasz między tymi miejscami? Ponadto, czy są jakieś zalety i wady korzystania z któregokolwiek z nich?

Czy są też plusy i minusy korzystania z któregokolwiek z nich?

Rejestr:

• + Stosunkowo standardowy w środowisku Windows.
• + Ogólnie dobre wsparcie ze strony instalatorów itp.
• - API specyficzne dla platformy, jeśli kiedykolwiek chcesz przenieść swoją aplikację.
• - Niezbyt czytelny dla człowieka.

Pliki INI:

• + Prosty format.
• + Przenośny.
• + Czytelny dla człowieka.
• - Przechowywanie bardziej złożonych informacji (np. Wszystkiego zagnieżdżonego na głębokości większej niż dwa poziomy) może być trudne.
• ?Może trzeba napisać własny parser (choć nie jest to trudne) lub użyć zewnętrznej biblioteki, takiej jak SimpleIni (dzięki Jonathan Merlet za komentarz).

Pliki XML (domyślam się, że jest to opcja .cfg):

• + Standardowy format.
• + Przenośny.
• + Obsługuje głęboko zagnieżdżone struktury.
• - Niezbyt czytelny dla człowieka.

Osobiście dla aplikacji Windows zwykle używam C # i idę z osobistym plikiem dla użytkownika, przechowywanym jako XML. Robię to zwykle, ponieważ czytelność dla ludzi nie jest zwykle priorytetem w rodzajach aplikacji, które piszę (a aplikacja powinna mieć edytor konfiguracji, w każdym przypadku), a w środowisku .NET bardzo łatwo jest pracować z XML. Bardzo często kończę na obiekcie UserConfiguration, który jest po prostu serializowany do i z pliku konfiguracyjnego - prawie nie wymaga programowania (parsowanie, rzutowanie), a twoja konfiguracja jest gotowa do użycia w środowisku o silnym typie.

Wybrałbym pliki INI, są one bardziej przyjazne dla człowieka:

[window]
width       = 600
height      = 350
position.x  = 400
position.y  = 200

[paths]
path1       = "/some/random/path/"
path2       = "/some/other/random/path/"

[user]
name        = "Yannis"
preference  = "INI"

XML może być dobrą opcją, ale nie może pobić prostoty i elegancji INI:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <window>
        <width>600</width>
        <height>350</height>
        <position>
            <x>400</x>
            <y>200</y>
        </position>
    </window>
    <paths>
        <path1>/some/random/path/</path1>
        <path2>/some/other/random/path/</path1>
    </paths>
    <user>
        <name>Robert</name>
        <preference>XML</preference>
    </user>
</configuration>

INI są również bardzo dobrze rozumiane i niezależne od platformy. Prawdopodobnie nie ma dla nich tylu narzędzi, co w przypadku plików XML, bo cóż, kto potrzebuje specjalistycznego narzędzia do odczytu i edycji pliku INI?

Preferuję pliki XML. Są hierarchiczne, możesz je naginać według własnej woli w prawie każdy możliwy do wyobrażenia sposób, są one dobrze zrozumiałe, niezależne od platformy, a także dostępny jest szeroki wachlarz oprogramowania do ich odczytu i zapisu.

Aby rozwinąć sugestię JAMA D Jeffa D. , oto krótkie wprowadzenie.

YAML jest podobny do JSON (w rzeczywistości JSON jest podzbiorem YAML od wersji 1.2 standardu YAML, a zatem może być przetwarzany prawidłowy JSON przez parsery YAML). Na pierwszy rzut oka główna różnica polega na tym, że YAML (domyślnie) używa wcięć zamiast nawiasów kwadratowych do wyświetlenia hierarchii. Zauważalny jest również brak cudzysłowów dla ciągów. Szybki przykład z góry:

configuration:
  window: 
    width:       600
    height:      350
    position:
      x:         400
      y:         200
  paths:
    path1:       some/random/path
    path2:       some/other/random/path
  user:
    name:        Joe Soap
    preference:  YAML

Lepsze przykłady można znaleźć na stronie YAML Wikipedii . Obsługa YAML istnieje dla większości głównych języków (szczegóły na stronie yaml.org ).

Zapomniałeś opcji: Baza danych. Jest to najczęściej używane w scenariuszach, w których użytkownicy logują się do aplikacji, gdy aplikacja nie może polegać na zalogowanym użytkowniku systemu Windows. Dzieje się tak na przykład, gdy aplikacja działa w systemie Windows w trybie kiosku.

Moje osobiste preferencje to pliki XML:

W większości przypadków nie oczekuję, że użytkownik będzie musiał edytować ustawienia konfiguracji, więc problem czytelności nie jest w tym przypadku argumentem.

Jeśli będą musieli je edytować, możesz udostępnić narzędzie do edycji - dzięki temu użytkownik nie zrobi nic dziwnego z danymi. Jeśli chcą przywrócić ustawienia domyślne, możesz po prostu powiedzieć im, aby usunęli plik x, co zrobi większość użytkowników.

Pamiętaj, że nadal musisz uważać, aby mieć uprawnienia do przechowywania pliku, ponieważ niektóre lokalizacje domyślnie nie mają dostępu do zapisu w systemie Windows 7 itp.

Pliki INI są dobrym standardowym sposobem przechowywania konfiguracji i są wypróbowane i przetestowane, ale wydają mi się trochę „Windows 3.1”!

Prawdopodobnie najlepsza opcja, jeśli chcesz, aby użytkownik majstrował przy swoich danych

Osobiście oderwałbym się od rejestru. Po pierwsze, nie możesz zagwarantować, że użytkownik ma niezbędne uprawnienia do odczytu / zapisu w dowolnym miejscu, w którym chcesz przechowywać swoje dane.

W nowszych systemach operacyjnych, w których występuje wirtualizacja rejestru, może to powodować poważne zamieszanie, ponieważ nie można „zobaczyć” zwirtualizowanych ustawień - to nas ugryzło niejednokrotnie, gdy spędziliśmy godziny próbując dowiedzieć się, dlaczego coś nie działa.