2015-05-20 10 views
5

Podążałem za niektórymi examples for ASP.NET 5 i natknąłem się, jak poprawnie odczytać "zagnieżdżone" wartości konfiguracyjne (jeśli jest to właściwe określenie).Jak poprawnie odczytać zagnieżdżone wartości konfiguracyjne z pliku config.json w ASP.NET5?

Oto odnośny fragment config.json:

{ 
    "ApplicationName" : "OwNextApp", 
    "AppSettings": { 
     "SiteTitle": "OwNext" 
    }, 
} 

i istotne części HomeController.cs:

public IActionResult About() 
{ 
    var appNestedNameFailed = _config.Get("AppSettings.SiteTitle"); 
    var appNestedNameSuccess = _config.Get("AppSettings:SiteTitle"); 
    var appName = _config.Get("ApplicationName"); 
    ViewBag.Message = string.Format(@"Your 
     APP NAME: {0}; 
     APP NESTED NAME FAILED: {1}; 
     APP NESTED NAME SUCCESS: {2}", 
      appName, appNestedNameFailed, appNestedNameSuccess); 

    return View(); 
} 

Wart appNestedNameFailed jest pusta (moja pierwsza próba przed badaniami). I appNestedNameSuccess ma wartość; po Zrobiłem badania i stwierdzono w badaniach na Configuration (pokazany odpowiedni kod):

// Assert 
Assert.Equal("IniValue1", config.Get("IniKey1")); 
Assert.Equal("IniValue2", config.Get("IniKey2:IniKey3")); 

Czy ktoś może wyjaśnić, dlaczego tak się dzieje? Dlaczego miałoby sens używanie : przez .? Z moich interakcji z danymi JSON zwykle zapisy . działają dobrze, np. How to access nested json data.

Również znalazłem podobny SO question, ale to nie daje wyjaśnienia, dlaczego został wybrany :.

Odpowiedz

7

To konwencja, którą zdecydowaliśmy, kiedy po raz pierwszy stworzyliśmy model konfiguracji. Zaczęliśmy od jsona i : jest tam ogranicznikiem.

W każdym razie, jeśli nie chcesz się martwić o te konwencje, zalecamy użycie ConfigurationBinder, która wiąże konfigurację z modelem (silnym obiektem typu). Here to testy, które mogą służyć jako przykład.

+0

Tak jak podejrzewano, był to tylko naturalny ogranicznik. Dzięki za potwierdzenie :) –

+0

Dzięki wszystkim. Lubię mocno wpisywać, więc używam 'ConfigurationBinder'. – CrnaStena

+0

fyi, linki są martwe – RSid

1

Zaglądając w głąb trzewi źródła JsonConfigurationFileParser z winą za ENTER/metod wyjścia, które wyglądają na:

private void VisitJObject(JObject jObject) 
{ 
    foreach (var property in jObject.Properties()) 
    { 
     EnterContext(property.Name); 
     VisitProperty(property); 
     ExitContext(); 
    } 
} 

private void EnterContext(string context) 
{ 
    _context.Push(context); 
    _currentPath = string.Join(":", _context.Reverse()); 
} 

private void ExitContext() 
{ 
    _context.Pop(); 
    _currentPath = string.Join(":", _context.Reverse()); 
} 

wydaje się, że zespół ASP.NET powinien opuścić więcej oświetlając zameldowania komentarze:).

Zgaduję, że w pliku config.json mogą znajdować się dane, które muszą zawierać ., podczas gdy : byłyby mniej powszechne. Na przykład:

"AppSettings": { 
    "Site.Title": "Is .NET getting faster?" 
}, 

To zły przykład, ale wydaje się rozsądne, że chcieli być „bezpieczne” jak to możliwe, korzystać z czegoś poza normę. Jeśli chcesz zapisać pełną nazwę typu, byłoby to nieco łatwiejsze bez martwienia się o bezpański okres.

"AppSettings": { 
    "ImportantTypeName": "WebApp.CoolStuff.Helpers.AwesomeClass" 
}, 
+0

Wydaje się to uzasadnione i jest również tym, o czym myślałem. Ale miałem nadzieję na coś bardziej pouczającego. Dziękuję za rozpatrzenie tego. – CrnaStena

+0

Patrząc bardziej na ten plik config.json, myślę, że wybrał ':', ponieważ jest używany do zagnieżdżania danych, np. '" AppSettings ": {. Tak czy inaczej. – CrnaStena

+0

Typowe jest zagnieżdżanie obiektów w jsonie z ':', ponieważ oznacza parę klucz/wartość. W rezultacie prawdopodobnie był najbardziej naturalnym ogranicznikiem. Niestety nie udało mi się znaleźć bardziej oficjalnej odpowiedzi dla Ciebie :). –

Powiązane problemy