Привязка библиотеки классов непосредственно к файлу конфигурации затрудняет возможность переопределения этой конфигурации в коде. Многие библиотеки, созданные в .NET Framework, страдали от этой проблемы, которая стала наиболее болезненной при попытке настроить библиотеку с использованием современных методов внедрения зависимостей. Microsoft намеренно усложнила эту задачу в .NET Standard.
Вместо того, чтобы конфигурировать современную библиотеку с использованием файлов, вы должны стремиться к тому, чтобы конфигурация передавалась в через конструкторы объектов, как и любая другая зависимость. Если у вас есть URL-адреса конфигурации, которые имеют логическое значение по умолчанию, вы можете просто поместить эти значения по умолчанию в свои объекты конфигурации.
public class MyClassConfiguration
{
public string Url { get; set; } = "https://example.com/some-default-location";
}
Один из способов облегчить проглатывание потребителем вашей библиотеки - создать бизнес-логику в классах с внедрением DI-дружественных конструкторов, а затем создать некоторые классы фасадов, предназначенные специально для их конструирования и предоставления значений по умолчанию. Хороший способ сделать это - использовать шаблон беглого построения, как описано в публикации DI-Friendly библиотеки Марка Симанна .
var foo =
new FooBuilder().WithUrl("https://example.com/override-the-default").Create();
После этого пользователь вашей библиотеки может решать, сохранять ли конфигурацию в виде кода или читать ее из файла конфигурации и передавать ее в вашу библиотеку.