My.Ioc 代码示例——避免循环依赖

本文的目的在于通过一些示例，向大家说明 My.Ioc 支持哪些类型的依赖关系。也就是说，如何设计对象不会导致循环依赖。

在 Ioc 世界中，循环依赖是一个顽敌。这不仅因为它会导致 Ioc 容器抛出异常，而且还因为它是不可预知的，尽管通过仔细的配置是可以尽量避免这个问题的。

当我们在 Ioc 容器中注册对象时，我们事先并不知道该对象与其他对象之间的依赖关系，因为依赖关系是由 Ioc 容器管理的。这种依赖关系要等到我们首次调用 container.Resolve(contractType) 时才能确定。而且，它还有可能会随着所依赖对象的注册/注销而发生变化。

因此，要想避免循环依赖问题，那么在设计对象时，仔细地思考该对象与其他对象之间的依赖关系，审慎地区分不同对象的职责就显得比较重要了。当然，对象设计是 Ioc 容器之外的事情了，我们没有办法加以约束。但是，即使您不使用 Ioc 容器，对象设计也是一个值得您深思熟虑的大问题。而一旦您选择使用 Ioc，那也意味着您的对象设计需要更多围绕 Ioc 来考虑。

其实，在 My.Ioc 中要想避免循环依赖也很简单，只要遵循一个原则即可，那就是 [不要在对象构造过程中引入循环依赖]。下面我们结合示例代码来讲解。

using System;
using System.Diagnostics;
using My.Ioc;
using My.Ioc.Exceptions;

namespace HowToAvoidCyclicDependency
{
    #region Test clazz

    #region Case 3

    public class Grade3
    {
        private readonly Room3 _room;

        public Grade3(Room3 room)
        {
            _room = room;
        }

        public Room3 Room
        {
            get { return _room; }
        }
    }
    public class Room3
    {
        public Grade3 Grade { get; set; }
    }

    #endregion

    #region Case 2

    public class Grade2
    {
        private readonly Room2 _room;

        public Grade2(Room2 room)
        {
            _room = room;
            room.Grade = this;
        }

        public Room2 Room
        {
            get { return _room; }
        }
    }
    public class Room2
    {
        public Grade2 Grade { get; set; }
    }

    #endregion

    #region Case 1

    public class Grade1
    {
        public Room1 Room { get; set; }
    }
    public class Room1
    {
        public Grade1 Grade { get; set; }
    }

    #endregion

    #endregion

    class Program
    {
        static void Main(string[] args)
        {
            var container = new ObjectContainer(false);
            Register(container);
            Resolve(container);

            Console.WriteLine("HowToAvoidCyclicDependency success...");
            Console.ReadLine();
        }

        static void Register(IObjectContainer container)
        {
            container.Register<Grade3>()
                .In(Lifetime.Transient());
            container.Register<Room3>()
                .WithPropertyAutowired("Grade")
                .In(Lifetime.Transient());

            container.Register<Grade2>()
                .In(Lifetime.Transient());
            container.Register<Room2>()
                .In(Lifetime.Transient());

            container.Register<Grade1>()
                .WithPropertyAutowired("Room")
                .In(Lifetime.Transient());
            container.Register<Room1>()
                .WithPropertyAutowired("Grade")
                .In(Lifetime.Transient());

            container.CommitRegistrations();
        }

        static void Resolve(IObjectContainer container)
        {
            var grade1 = container.Resolve<Grade1>();
            Debug.Assert(grade1 == grade1.Room.Grade);
            var room1 = container.Resolve<Room2>();
            Debug.Assert(room1 == room1.Grade.Room);

            // No cyclic dependency in constructor
            var grade2 = container.Resolve<Grade2>();
            Debug.Assert(grade2 == grade2.Room.Grade);

            try
            {
                // Cyclic dependency in constructor
                // The call path is: Grade => Room => Grade
                var grade3 = container.Resolve<Grade3>();
            }
            catch (Exception ex)
            {
                Debug.Assert(ex is CyclicDependencyException);
            }
        }
    }
}

在示例代码中，我们设计了三对 Grade/Room 类，用来演示三种不同的情况。

先来看 Grade1/Room1。

public class Grade1
{
    public Room1 Room { get; set; }
}
public class Room1
{
    public Grade1 Grade { get; set; }
}

我们看到这两个类的属性相互引用对方，但它们都没有定义构造函数。这里，我们以 Grade1 为例来分析一下它们的构造过程。

当我们需要一个 Grade1 对象时，容器首先调用其构造函数为我们创建一个 Grade1 对象。创建好 Grade1 对象之后，我们看到它需要注入一个 Room1 类型的属性。这样容器又会为我们创建一个 Room1 对象。随后，我们看到 Room1 也需要注入一个 Grade1 类型的属性。此时，由于之前已经创建好一个 Grade1 对象，因此容器在这里便会复用该 Grade1 对象（这一点很关键），以完成 Room1 对象的创建。随着 Room1 对象创建完成，容器跟着将该对象注入到 Grade1 的 Room 属性中，这样 Grade1 也创建完成了。因此，这里不会导致循环依赖，所以我们运行下面的代码不会导致异常：

var grade1 = container.Resolve<Grade1>();
Debug.Assert(grade1 == grade1.Room.Grade);
var room1 = container.Resolve<Room2>();
Debug.Assert(room1 == room1.Grade.Room);

接下来，我们看 Grade2/Room2。

public class Grade2
{
    private readonly Room2 _room;

    public Grade2(Room2 room)
    {
        _room = room;
        room.Grade = this;
    }

    public Room2 Room
    {
        get { return _room; }
    }
}
public class Room2
{
    public Grade2 Grade { get; set; }
}

当我们构造 Grade2 对象时，并不会引起循环依赖。因为我们看到 Grade2 虽然在构造函数中需要 Room2，但在构造 Room2 的过程中并不需要 Grade2（因为 Room2 没有定义构造函数，而且也不需要在自身的构造过程中注入 Grade2 这个属性），所以不会有循环依赖问题。

最后我们来看 Grade3/Room3。

public class Grade3
{
    private readonly Room3 _room;

    public Grade3(Room3 room)
    {
        _room = room;
    }

    public Room3 Room
    {
        get { return _room; }
    }
}
public class Room3
{
    public Grade3 Grade { get; set; }
}

我们看到 Grade3 在构造函数中需要一个 Room3 类型参数，而 Room3 类型虽然没有定义构造函数，但它在构造过程中要求注入一个 Grade3 类型的属性值。这样就引起了问题。因为当 Grade3 需要一个 Room3 对象的时候，Room3 对象尚未创建，这样容器就需要先创建一个 Room3 对象。但容器在创建 Room3 对象的过程中，又需要注入一个 Grade3 对象。然而此时最初的 Grade3 尚未创建完成（其构造函数已经被调用，但尚未完成），还无法在此处复用。因此，容器又要再创建一个新的 Grade3 对象以满足 Room3 的构造需要。随后，这个新的 Grade3 又需要一个新的 Room3，而后面这个新的 Room3 又需要一个新的 Grade3...这样永无休止地纠缠下去，这个构造过程永远不会完成。如果用比较简洁的方式来表述的话，上述创建过程的依赖路径如下：Grade3 => Room3 => Grade3 => Room3 => Grade3....

这样我们就明白了，只要我们在设计类时，注意避免产生如上所述的依赖路径，就能够有效地防止循环依赖的问题。其实，也就是遵循上面那个原则：[不要在对象构造过程中引入循环依赖]。

本文示例代码以及 My.Ioc 框架源码可在此处获取。