Q:

Eliminate boilerplate parameters using Ninject in .NET MVC

A lot of our repositories are plagued with boilerplate parameters concerning date range, as our application is very date-range sensitive as such: 
public static IEnumerable<Records> GetByClient(int clientId, DateTime start, DateTime end){}
public static IEnumerable<Records> GetByRegion(int regionId, DateTime start, DateTime end){}

Is there a good way to resolve this by passing DateTime start and DateTime end from http request level all the way down to repository level using Ninject in .NET MVC ? 
These repositories would have the "Request" scope, hence disposed after each request, and since each request only has one time range, Ninject would create repositories with appropriate start / end time as repository level properties? and repo methods would look somewhat like this: 
public static IEnumerable<Records> GetByClient(int clientId){
  query.Where(c=>c.Date >= startDate && c.Date <= endDate)...

}

I'm sure this has been done many times before, any tip would help. Thanks. 

A:

Expanding on Steven's answer, there's two ways how you can get the data on the ninject context.
a) Putting the IDateRangeContext on the ninject context as IParameter p.Ex by using a factory: use IResolutionRoot.Get<Foo>(new ConstructorArgument("dateRangeContext", dateRangeContext, true) --> true is for inheriting.
This way any object instanciated by the foo request, including dependencies, can have the IDateRangeContext constructor injected as parameter named "dateRangeContext" (you could also roll your own IParameter which maches the type / IDateRangeInterface but doesn't care what the argument name is).
b) Bind<IDateRangeContext().To<DateRangeContext>().InRequestScope(), then have it injected @ http level and set Start & End properties there. For better separation, you can also have the context implement two interfaces:
public interface IDateRangeContext {
    DateTime Start { get; }
    DateTime End { get;
}

public interface IDateRangeContextWithSetter : IDateRangeContext {
    DateTime Start { get; set; }
    DateTime End { get; set; }
}

and then bind both to the same instance in RequestScope:
IBindingRoot.Bind<IDateRangeContext, IDateRangeContextWithSetter>().To<DateRangeContext>().InRequestScope();

The context preservation extension might also be useful, in case you are late-creating (through "factory") objects which need to be in the same context as well: 
https://github.com/ninject/ninject.extensions.contextpreservation/wiki
https://www.nuget.org/packages/Ninject.Extensions.ContextPreservation/2.2.0.5

