c# - Constructor injection with non-dependency parameters -

i have interface itradingapi so:

public interface itradingapi {     iorder createorder(...);     ienumerable<symbol> getallsymbols();     // ... } 

this meant facade different apis of vendors of trading software. view model has dependency on trading api in constructor:

public class mainviewmodel {     public mainviewmodel(itradingapi tradingapi) { /* ... */ }     // ... } 

i use ninject ioc container, create instance of view model this:

var vm = kernel.get<mainviewmodel>(); 

now, problem:

the implementation of itradingapi might need additional parameters work.
example:

• one vendors api uses tcp/ip internally, need hostname , port.
• another vendor uses com object. here don't need info.
• a third vendor needs username , password of account.

in spirit of not allowing incomplete objects, added these parameters constructors of concrete implementations.

now, not sure, how work. clearly, these additional parameters not belong interface, because specific each implementation.
on other hand, these additional parameters need entered end-user , passed implementation of itradingapi, meaning user of itradingapi needs intimate knowledge concrete implementation.
how solve dilemma?

update:
1 approach create itradingapiprovider exposes list of required parameters. view automatically create input form these parameters databound parameters in itradingapiprovider. now, when itradingapi instance requested provider, can make use of these parameters create instance of concrete implementation. implementation of itradingapiprovider , itradingapi tightly coupled, think not problem long each implementation of itradingapi comes corresponding implementation of itradingapiprovider.

based on information far put forth here, i'd point out 1 or 2 things:

first of all, whether or not concrete configuration values supplied @ composition time or first available @ runtime user input makes huge difference. long can resolved @ composition time things easy because can read values environment , supply them appropriate constructors. so, rest of answer i'm going assume things harder , need values user @ runtime.

instead of attempting come general-purpose configuration api i'd rather model what's going on. in case sounds me we're collecting configuration values user, why not model explicitly?

product trader

define interface this:

public interface itradingapitrader {     itradingapi create(type apitype); } 

here, it's assumed apitype can cast itradingapi, can't enforced compiler. (the reason i'm calling 'trader' because variation of product trader pattern (plopd 3).)

how different before?

well, can implement create method showing user interface each type of itradingapi. each concrete user interface gathers values required own concrete itradingapi implementation , subsequently returns correctly configured instance.

if know concrete types @ compile time, other variations include these:

public interface itradingapitrader {     itradingapi createmt4tradingapi();      itradingapi createfootradingapi();      itradingapi createbartradingapi();      // etc. } 

perhaps can (although haven't tried compile this):

public interface itradingapitrader {     itradingapi create<t>() t : itradingapi; } 

note don't need define first itradingapitrader's create method based on type - identifier (such enum or string) might instead.

visitor

if set of itradingapi (finite and) known @ design time, visitor design pattern might offer alternative.

if use visitor, can make visit method show appropriate user interface , subsequently use values collected user interface create appropriate itradingapi instance.

basically variation on previous 'solution' product trader implemented visitor.