Извините за этот длинный вопрос, он помечен вики, потому что я прошу что-то, на что не может быть очень конкретного ответа. Если он закрыт, пусть будет так.

Мой главный вопрос заключается в следующем:

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

Я на третьей итерации переписываю свой контейнер IoC. Вторая итерация состояла в том, чтобы улучшить производительность, эта третья итерация должна была решить некоторые проблемы расширяемости и проблемы разделения.

По сути, проблема с расширяемостью заключается в том, что ее нет. Недавно я хотел использовать службу, срок службы которой истек, и после ее истечения разрешить новую копию. Например, читайте файл конфигурации каждую минуту, но не чаще. Это не было поддержано моим текущим IoC-решением, но единственный способ добавить его - пойти в библиотеку базовых классов и добавить туда поддержку. Для меня это означает, что мне не удалось создать расширяемую библиотеку классов. Честно говоря, я не собирался встраивать в него расширяемость, но тогда я не до конца осознавал, насколько больно было бы входить и добавлять что-то подобное позже.

Я смотрю на свой свободный интерфейс для настройки, и, поскольку я хочу встроить в интерфейс полную расширяемость (или избавиться от него, чего я не хочу делать), мне нужно действовать по-другому.

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

Код, который использует свободные интерфейсы, обычно очень легко читается

Другими словами, это:

ServiceContainer.Register<ISomeService>()
    .From.ConcreteType<SomeService>()
    .For.Policy("DEBUG")
    .With.Scope.Container()
    .And.With.Parameters
        .Add<String>("connectionString", "Provider=....")
        .Add<Boolean>("optimizeSql", true);

легче читать, чем это:

ServiceContainer.Register(typeof(ISomeService), typeof(SomeService),
    "DEBUG", ServiceScope.Container, new Object[] { "Provider=...", true });

Таким образом, читаемость является одной из проблем.

Тем не менее, руководство программиста - это другое, что не легко понять, читая существующий код, в Интернете или в редакторе.

В основном, когда я набираю это:

ServiceContainer.Register<ISomeService>()
    .From.|
          ^-cursor here

и тогда intellisense покажет доступные типы разрешения. После того, как я выбрал это, и напишите:

ServiceContainer.Register<ISomeService>()
    .From.ConcreteType<SomeService>()
    .For.|

тогда я получаю доступными только после ключевого слова "For", например, "Политика" и тому подобное.

Тем не менее, это большая проблема? Были ли у вас свободно используемые интерфейсы? Очевидное препятствие для определения интерфейса состоит в том, чтобы создать класс или интерфейс со всеми ключевыми словами и всем таким, чтобы значение intellisense после каждой запятой содержало все, но это также могло бы привести к тому, что это допустимо (например, компилирует) код:

ServiceContainer.Register<ISomeService>()
    .From.ConcreteType<SomeService>()
    .From.Delegate(() => new SomeService())
    .From.With.For.Policy("Test");

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

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

Но это типично? Так как я хочу иметь возможность добавлять несколько таких ключевых слов, таких как тип распознавателя (ConcreteType, Delegate и т. Д.), Тип области действия (Factory, Container, Singleton, Cache и т. Д.) В качестве методов расширения, чтобы программы могут определять свои собственные способы сделать это без необходимости входить и изменять базовые классы, это означает, что мне нужно будет предоставить интерфейсы для всех промежуточных остановок и позволить фактическим важным ключевым словам быть. Реализация для этих ключевых слов затем должна выбрать один промежуточный-стоп-интерфейс для возврата, в зависимости от ситуации.

Похоже, мне нужно определить интерфейс для:

xyz.From.xyz.From.<Resolver here>.<Resolver here>.With.<Resolver here>.For.

и т.д., но это выглядит фрагментированным для меня.

Может ли кто-нибудь, имеющий опыт работы с беглыми интерфейсами, вернуться и прочитать мой цитируемый ответ в верхней части страницы и попытаться дать мне короткий ответ?