Как конфигурация влияет на архитектуру приложения

ya ne poimu smisla voobshe etogo voprosa. ya otvetil: JSON eto OBJECT notation format.

Как это мешает его применению для задач в посте?

Dlya postroeniya ABSTRACTNIX ierarxiy pamyati on neudoben

У нас не абстрактная иерархия, у нас вполне конкретная задача…

Naprimer vy mojete imet xot 100 noudov s odnim i tem je imenem.

… в рамках которой это ваше требование избыточно. Откроем и посмотрим:

tests
       {
           test
           {
           ...
           }
           test
           {
            ...
           }
       }

serializers
      {
           serializer
           {
           ...
           }        
           serializer
           {
           ...
           }        
      }

Это же два тривиальных массива: tests и serializers, и их можно так и записать, не потеряв ни грама семантики.

Esli vam lichno nujen JSON eto vashe pravo, no vy ubedites sami chto isplzovat ego vmesto Laconic formata v razy neudobnee.

Где можно взять пакет для чтения laconic, чтобы я мог в этом убедиться?

v tom chto eto ispolzuetsya v desyatkax nest, takix kak ustanoivka programmnogo obespecheniya na servera.

Да какая мне разница, где это используется, мне мою задачу надо решить.

vy vse pytaetes dokazat chto u vas ne Unistack i vy s etim happy.

Я не могу говорить за «всех», но лично я весьма рад тому, что у меня не монолитные фреймворки — иначе бы гранулярность повторного использования была бы ужасающей.

u vas vyigrish budet togda kogda vy poimete chto pishete odno i tozhe 25 raz v kajdom proekete na 3x yazikax i 10 formatax…

Не пишу. Как раз благодаря тому, что если задачу можно делегировать сторонней библиотеке — она делегируется, и я об этом больше не думаю. А бойлерплейт неизбежен, его просто может быть меньше или больше.

Понимаете ли, беда обсуждаемого поста в том, что заголовок нам говорит про то, как конфигурация влияет на приложение, а сам пост — про то, как NFX влияет на приложение. Оставив в стороне вопрос, надо ли решать описанную задачу с помощью конфигурации, мы встаем перед вопросом: а что такого уникального в NFX для данной задачи, с чем не справились бы общепринятые решения?

Ну да, System.Configuration для этого нездорово громоздок, с этим никто не спорит. Но любое другое решение, позволяющее сериализовать и прочитать граф, справится на ура. XML? Да (писать много буков, правда). JSON? Да. YAML? Да.

Более того, все эти решения еще бы и дали нормальный типизованный граф, без необходимости проходить по узлам вручную, как вот в этом примере:

foreach(var snode in node[CONFIG_SERIALIZERS_SECTION].Children.Where(cn => cn.IsSameName(CONFIG_SERIALIZER_SECTION)))
{
  var item = FactoryUtils.Make<Serializer>(snode, args: new object[]{this, snode});
  m_Serializers.Register( item  );
}