How to pass parameters into constructors when using IoC containers?

I have a class somewhere with a mix of reference classes that can be resolved by IoC and value types (or some other types) that can only be resolved at runtime

This is where you go wrong. You should not mix compile time dependencies with runtime data when you compose components. Your object graphs should be static (and preferably stateless) and runtime data should be passed through the object graph using method calls after the complete object graph is constructed. This can cause a tremendous simplification in the development of your application, because it allows your object graphs to be statically verified (using a tool, unit tests or by using Pure DI) and it prevents having the trouble you are having today.

In general, you have two options to solve this:

  1. You pass the data on to lower level components through method calls.
  2. You retrieve the data by calling a method on an injected component.

Which solution to take depends on the context.

You would typically go for option one in case the data is specific to the handled request and would be part of the use case you're handling. For instance:

public interface IFeedUnitOfWorkProvider
{
    IFeedUnitOfWork GetUnitOfWork(NFLFileType fileType, object feed);
}

Here the IFeedUnitOfWorkProvider contains a GetUnitOfWork method that requires the runtime parameters as input. An implementation might look like this:

public class FeedUnitOfWorkProvider : IFeedUnitOfWorkProvider
{
    private readonly IConverterMappings converterMappings;
    private readonly IContext context;

    public FeedUnitOfWorkProvider(IConverterMappings converterMappings,
        IContext context) {
        this.converterMappings = converterMappings;
        this.context = context;
    }

    public IFeedUnitOfWork GetUnitOfWork(NFLFileType fileType, object feed) {
        return new NFLFeedUnitOfWork(fileType, feed, this.converterMappings,
            this.context);
    }       
}

A few things to note here:

  • All statically known dependencies are injected through the constructor, while runtime values are injected through method calls.
  • The connectionString value is unknown to the FeedUnitOfWorkProvider. It's not a direct dependency and the provider doesn't have to know about its existence.
  • Assuming that the connectionString is a configuration value that does not change at runtime (and is typically stored in the application's configuration file), it can be injected into the NFLContext the same way as other dependencies are injected. Note that a configuration value is different from a runtime value, because it won't change during the lifetime of the application.

The second option is especially useful when you're dealing with contextual information. This is information that is important for an implementation, but should not be passed in as with the previous example. A good example of this is information about the user on whos behalf the request is running. A typical abstraction for this would look like this:

public interface IUserContext {
    string CurrentUserName { get; }
}

This interface can be injected into any consumer. Using this abstraction, the consumer can query the user name at runtime. Passing through the user name with the rest of the request data would typically be awkward, because this would allow the caller to change (or forget) the user name, making the code just harder to work with, harder to test, more error prone. Instead we can use the IUserContext:

public IFeedUnitOfWork GetUnitOfWork(NFLFileType fileType, object feed) {
    if (this.userContext.CurrentUserName == "steven") {
        return new AdminUnitOfWork(this.context);
    }
    return new NFLFeedUnitOfWork(fileType, feed, this.converterMappings,
        this.context);
}

How a IUserContext implementation should look like will highly depend on the type of application you're building. For ASP.NET I imagine something like this:

public class AspNetUserContext : IUserContext {
    string CurrentUserName {
        get { return HttpContext.Current.User.Name; }
    }
}