标签: ioc-container

我一直在使用依赖注入(DI)一段时间,在构造函数,属性或方法中注入.我从未觉得需要使用控制反转(IoC)容器.但是,我读的越多,我觉得社区使用IoC容器的压力就越大.

我使用.NET容器,如StructureMap,NInject,Unity和Funq.我仍然没有看到IoC容器如何使我的代码受益/改进.

我也害怕在工作中开始使用容器,因为我的许多同事都会看到他们不理解的代码.他们中的许多人可能不愿意学习新技术.

请说服我需要使用IoC容器.当我在工作中与开发人员交谈时,我将使用这些论点.

关于控制(IoC)的反转是如何工作的,我有点困惑Spring.

假设我有一个名为的UserServiceImpl实现UserService接口的服务类.

怎么会这样@Autowired？

而在我Controllers,我怎么会instantiate在instance这个服务的？

我会做以下吗？

UserService userService = new UserServiceImpl();

冒着进入神圣战争领域的风险,这些流行的DI/IoC框架有哪些优点和缺点,可以轻松地被认为是最好的？..:

• Ninject
• 统一
• Castle.Windsor
• Autofac
• StructureMap

我还没有列出其他用于C#的DI/IoC框架吗？

在我的用例的上下文中,我正在构建一个客户端WPF应用程序,一个WCF/SQL服务基础架构,易用性(特别是在清晰简洁的语法方面),一致的文档,良好的社区支持和性能都是重要因素在我的选择.

更新:

所引用的资源和重复问题似乎已经过时,那些了解所有这些框架的人能否提出并提供一些真正的见解？

我意识到关于这个主题的大多数意见可能都有偏见,但我希望有人花时间研究所有这些框架,并且至少进行了一般性的客观比较.

如果以前没有这样做,我非常愿意自己进行调查,但我认为至少有一些人已经这样做了.

第二次更新:

如果您有多个DI/IoC容器的使用经验,请对这些容器的优缺点进行排序和总结,谢谢.这不是发现人们制作的所有模糊小容器的练习,我正在寻找流行(和主动)框架之间的比较.

我发现我的构造函数开始看起来像这样:

public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... )

随着参数列表不断增加.由于"容器"是我的依赖注入容器,为什么我不能这样做:

public MyClass(Container con)

每个班级？有什么缺点？如果我这样做,感觉我正在使用一个美化的静电.请分享您对IoC和依赖注入疯狂的看法.

我试图让Unity管理我的对象的创建,我希望有一些在运行时才知道的初始化参数:

目前,我能想到的方法是在接口上使用Init方法.

interface IMyIntf {
  void Initialize(string runTimeParam);
  string RunTimeParam { get; }
}

然后使用它(在Unity中)我会这样做:

var IMyIntf = unityContainer.Resolve<IMyIntf>();
IMyIntf.Initialize("somevalue");

在这种情况下,runTimeParamparam是在运行时根据用户输入确定的.这里的简单案例只返回值,runTimeParam但实际上参数将类似于文件名,初始化方法将对文件执行某些操作.

这会产生许多问题,即该Initialize方法在界面上可用并且可以多次调用.在实现中设置一个标志并在重复调用时抛出异常Initialize似乎很笨重.

在解析我的界面时,我不想知道有关实现的任何信息IMyIntf.但是,我想要的是知道这个接口需要一定的一次初始化参数.有没有办法以某种方式注释(属性？)具有此信息的接口,并在创建对象时将它们传递给框架？

编辑:更多地描述了界面.

是否可以在运行时注册服务,这意味着在ContainerBuilder构建并Container创建(并ContainerBuilder处置)之后？

我理解DI背后的概念,但我只是在学习不同的IoC容器可以做什么.似乎大多数人都主张使用IoC容器来连接无状态服务,但是如何将它们用于实体等有状态对象呢？

无论是对还是错,我通常会用行为填充我的实体,即使这种行为需要外部类.例:

public class Order : IOrder
{

    private string _ShipAddress;
    private IShipQuoter _ShipQuoter;

    public Order(IOrderData OrderData, IShipQuoter ShipQuoter)
    {
        // OrderData comes from a repository and has the data needed 
        // to construct order
        _ShipAddress = OrderData.ShipAddress;  // etc.
        _ShipQuoter = ShipQuoter;

    }

    private decimal GetShippingRate()
    {
        return _ShipQuoter.GetRate(this);
    }
}

如您所见,依赖项是Constructor Injected.现在提出几个问题.

1. 让您的实体依赖于诸如ShipQuoter之类的外部类别是否被视为不良做法？如果我正确理解定义,消除这些依赖性似乎会导致我陷入贫血领域.

2. 使用IoC容器来解决这些依赖关系并在需要时构建实体是不好的做法吗？是否有可能做到这一点？

感谢您的任何见解.

我正在阅读关于依赖倒置和解耦的理论,我看不出两者之间的区别.

依赖性反转讨论了解耦功能组件,以便更高级别的组件不依赖于更低级别的组件.

解耦谈论同样的事情以及如何实现它.但是我们的IoC容器会让事情变得更糟.为什么它们不是称为依赖性反转容器或更好的依赖注入容器,因为它们服务于独立组件的运行时耦合？

然后我们有控制反转.这与Dependency Inversion基本相同,不是吗？为什么有三个术语描述同一个东西？还是我失明了？

1. 三者有什么区别？
2. IoC在IoC容器中需要做什么？

我决定开始使用Ninject并面临一个问题.说我有以下场景.我有一个IService接口和2个实现此接口的类.而且我还有一个类,它有一个构造函数获取IService和一个int.如何使用Ninject创建此类的实例(我不想硬连接这个int,我想在每次获取实例时都传递它)？

以下是一些说明情况的代码:

interface IService
{
    void Func();
}

class StandardService : IService
{
    public void Func()
    {
        Console.WriteLine("Standard");
    }
}

class AlternativeService : IService
{
    public void Func()
    {
        Console.WriteLine("Alternative");
    }
}


class MyClass
{
    public MyClass(IService service, int i)
    {
        this.service = service;
    }

    public void Func()
    {
        service.Func();
    }

    IService service = null;
}
class Program
{
    static void Main(string[] args)
    {
        IKernel kernel = new StandardKernel(new InlineModule(
            x => x.Bind<IService>().To<AlternativeService>(),
            x => x.Bind<MyClass>().ToSelf())); …

我对laravel在IOC容器和外墙方面提供的所有好东西感到有些困惑.由于我不是一位经验丰富的程序员,因此学习起来势不可挡.

我想知道,这两个例子有什么区别:

1. 'Foo'的门面并通过容器注册 App::bind()

2. 'Foo'的门面并通过容器注册 App::singleton()

在我的最佳理解Foo::method()中将被重写,$app->make['foo']->method()因为在第一个示例Foo中将创建类的多个实例,并且在第二个示例中,因为它通过a绑定App::singleton(),所以Foo每次调用该对象上的Method时都将返回相同的实例.

如果这个问题的答案显而易见,我很抱歉,但我找不到任何关于这个问题的确认,也没有明确解释.