Внедрение конструктора с параметрами, не зависящими от зависимости

У меня есть интерфейс ITradingApi примерно так:

public interface ITradingApi
{
    IOrder CreateOrder(...);
    IEnumerable<Symbol> GetAllSymbols();
    // ...
}

Это должен быть фасад для различных API-интерфейсов поставщиков программного обеспечения для торговли . Моя модель представления зависит от этого торгового API в своем конструкторе:

public class MainViewModel
{
    public MainViewModel(ITradingApi tradingApi) { /* ... */ }
    // ...
}

Я использую Ninject в качестве контейнера IoC, поэтому я создам экземпляр моей модели представления следующим образом:

var vm = kernel.Get<MainViewModel>();

Теперь моя проблема:

реализация ITradingApi может потребовать дополнительных параметров для работы.
Пример:

• Один поставщик API использует TCP / IP для внутренних целей, поэтому мне нужно имя хоста и порт.
• Другой поставщик использует COM-объект. Здесь мне не нужна информация.
• Третьему поставщику требуются имя пользователя и пароль учетной записи.

В духе недопущения использования неполных объектов я добавил их в качестве параметров в конструкторы конкретных реализаций.

Теперь я не уверен, как это сработает. Очевидно, что эти дополнительные параметры не относятся к интерфейсу, поскольку они специфичны для каждой реализации.
С другой стороны, эти дополнительные параметры должны быть введены конечным пользователем, а затем переданы в реализацию ITradingApi , что означает, что пользователю ITradingApi необходимы глубокие знания о конкретном реализация.
Как решить эту дилемму?

ОБНОВЛЕНИЕ:
Один из подходов может заключаться в создании ITradingApiProvider , который предоставляет список необходимых параметров. Представление может автоматически создавать форму ввода для этих параметров, которая привязана к параметрам в ITradingApiProvider . Теперь, когда у поставщика запрашивается экземпляр ITradingApi , он может использовать эти параметры для создания экземпляра конкретной реализации. Очевидно, что реализация ITradingApiProvider и ITradingApi тесно связаны, но я думаю, что это не проблема, если каждая реализация ITradingApi поставляется с соответствующей реализацией ITradingApiProvider .