通常我会将我的服务类包装在处理DI的工厂模式中,如下所示：

public static class SomeTypeServiceFactory
{
    public static SomeTypeService GetService()
    {
        SomeTypeRepository someTypeRepository = new SomeTypeRepository();
        return = new SomeTypeService(someTypeRepository);

    }

}

对我来说,这似乎很像模块：

public class WarriorModule : NinjectModule {
    public override void Load() {
      Bind<IWeapon>().To<Sword>();
      Bind<Samurai>().ToSelf().InSingletonScope();
    }
}

每个类都有它的相关模块,你将它的构造函数绑定到一个具体的实现.虽然ninject代码少了1行,但我没有看到优势,无论何时添加/删除构造函数或更改接口构造函数的实现,您都必须更改模块,就像在工厂中一样没有？所以没有看到这里的优势.

然后我想我可以想出一个基于通用约定的工厂,如下所示：

public static TServiceClass GetService<TServiceClass>()
        where TServiceClass : class
    {
        TServiceClass serviceClass = null;

        string repositoryName = typeof(TServiceClass).ToString().Replace("Service","Repository");
        Type repositoryType = Type.GetType(repositoryName);

        if (repositoryType != null)
        {
            object repository = Activator.CreateInstance(repositoryType);
            serviceClass =  (TServiceClass)Activator.CreateInstance(typeof (TServiceClass),new[]{repository});
        }

        return serviceClass;
    }

然而,由于两个原因,这很糟糕：1)它严格依赖于命名约定,2)它假设存储库永远不会有任何构造函数(不是真的),而服务的唯一构造函数将是它的相应repo(也不是真的).我被告知“嘿,这是你应该使用IoC容器的地方,这里会很棒！”因此我的研究开始……但我只是没有看到它并且无法理解它……

是否有某种方式ninject可以自动解析类的构造函数而没有特定的声明,这样在我的通用工厂中使用它会很棒(我也意识到我可以使用反射手动执行此操作,但这是性能损失,ninject说正确他们的页面他们不使用反射).

对此问题的启发和/或展示如何在我的仿制工厂中使用它将非常感谢！

编辑：答案

所以,由于下面的解释,我非常了解ninject的真棒,我的通用工厂看起来像这样：

public static class EntityServiceFactory
{
    public static TServiceClass GetService<TServiceClass>()
        where TServiceClass : class
    {
        IKernel kernel = new StandardKernel();

        return kernel.Get<TServiceClass>();
    }
}

非常棒.由于具体类具有隐式绑定,因此一切都会自动处理.