ninject

I am using Ninject together with ASP.NET MVC 4. I am using repositories and want to do constructor injection to pass in the repository to one of the controllers. This is my Repository interface: public interface IRepository<T> where T : TableServiceEntity { void Add(T item); void Delete(T item); void Update(T item); IEnumerable<T> Find(params Specification<T>[] specifications); IEnumerable<T> RetrieveAll(); void SaveChanges(); } The AzureTableStorageRepository below is an implementation of IRepository<T> : public class AzureTableRepository<T> : IRepository<T> where T : TableServiceEntity {

I have an IConfig object that contains settings used throughout my application. At the moment, I inject the entire object into the constructor of each object that needs it, as follows: public interface IConfig { string Username { get; } string Password { get; } //... other settings } public class Foo : IFoo { private readonly string username; private readonly string password; public Foo(IConfig config) { this.username = config.Username; this.password = config.Password; } } The downside is that IConfig contains a large number of settings because it's deserialised from an overall config file, so

In Ninject3 there's a new .ToConstructor feature . As described, it helps to strongly-type constructor arguments like: Bind<IMyService>().ToConstructor( ctorArg => new MyService(ctorArg.Inject<IFoo>(), ctorArg.Inject<IBar>())); What's actually the difference between using .ToConstructor and .ToMethod in an almost the same way: Bind<IMyService>().ToMethod( x => new MyService(x.Kernel.Get<IFoo>(), x.Kernel.Get<IBar>())); Is it just a syntax sugar to avoid using Kernel.Get<>() or is there something more that I'm missing? The first case behaves like To<MyService>() except that you explicitly

How do bind my interface to a concrete class in a different assembly? I have the following projects in my solution: Foo.Data Foo.Domain In Structure Map I add my two assembly names to the StructureMap.config file and a then using the PluginFamily and Pluggable attributes map my interfaces to my concrete class'. How can accomplish the same thing with Ninject? I'll make a couple of assumptions here. You have an interface named IBar in your Foo.Domain project and you have a concrete class called BarClass in your Foo.Data project. You in fact reference Foo.Domain project in your Foo.Data project

Something that has been bugging me since I read an answer on another stackoverflow question (the precise one eludes me now) where a user stated something like " If you're calling the Service Locator, you're doing it wrong. " It was someone with a high reputation (in the hundred thousands, I think) so I tend to think this person might know what they're talking about. I've been using DI for my projects since I first started learning about it and how well it relates to Unit Testing and what not. It's something I'm fairly comfortable with now and I think I know what I'm doing. However, there are a

Im trying to implement an unit of work pattern by passing an unit of work instance into my repositories. Relevant code from Global.asax. public class SiteModule : NinjectModule { public override void Load() { Bind<IUnitOfWork>().To<SqlUnitOfWork>() .InRequestScope() .WithConstructorArgument("connectionString", ConfigurationManager.ConnectionStrings["Entities"].ConnectionString); Bind<IProductRepository>().To<ProductRepository>(); Bind<ICategoryRepository>().To<CategoryRepository>(); } } Repository constructors: public class ProductRepository { IUnitOfWork unitOfWork; public ProductRepository

What is an IoC container? What is an IoC/DI framework? Why do we need a framework for IoC/DI? Is there any relationship between IoC/DI and AOP? What is Spring.net/ninject with respect to IoC and AOP? JMSA, James Kovacs wrote a fantastic article which covers many of your questions I would recommend reading it Here Spring.Net, Ninject, Unity, Castle Windsor, Autofac are all IOC containers which are configurable in different ways, many of them do also support AOP. Frameworks for IOC/DI are useful because they provide standard mechanisms, for example if you are hiring a new developer it is much