依赖注入(Dependency Injection)模式的学习(2)——初窥门径

在老早以前咱就非常重视软件的测试——特别是自动化的测试。首先是单元测试,再就是业务上、界面上的一些逻辑方面的验证。无论是哪种,都对模块之间的低耦合性要求非常之高。

假如我们有一个比较简单的系统,分为UI层A,业务层B,数据访问层C,业务层B还要和外部系统D通信。以对B进行单元测试为例,在这种情况下,设计软件的时候我们必须要考虑到,B不能依赖于A、C和D,更甚者,B中的任何一个类都不应该依赖于B中的其他类。

举一个简单的例子吧,假如我们在B层有一个ATM类,其中有一个bool ValidateCard(string cardID, string password)方法,UI层会调用这个方法判断用户提供的卡号和密码是否匹配;然后,我们的ATM类会:

  • 调用C层的UserRepository类去数据库中取与卡号匹配的用户;
  • 将取出来的用户传给D系统的UserService服务的bool ValidateUser(Int64 userId)判断这个用户是否在银行的黑名单里面;
  • 调用C层的CardRepository类去数据库中取该卡片的密码,并与UI层提供的密码进行匹配。

酱紫的话,我们应该如何设计B这个类呢?

 

方案一:

    public class ATM
    {

        public bool ValidateCard(string cardId, string password)
        {
            UserRepository user_repository = new UserRepository();
            CardRepository card_repository = new CardRepository();
            UserService user_service = new UserService(ATMHelper.UserServiceAddress);

            Int64 user_id = user_repository.GetUserIdByCardId(cardId);
            if (user_id <= 0) return false;  //Not found in database

            user_service.OpenConnection();
            if (!user_service.ValidateUser(user_id))
                return false;

            string correct_password = card_repository.GetPassword(user_id);
            return correct_password == password;
        }

    }

酱紫显然是不行的,因为模块之间的耦合性太强了,如果没有C和D,B完全无法工作。这样会导致以下两个问题:

  • 假如我们给ValidateCard做单元测试,那么得先把数据库和D系统搭建好。

为此,我们必须先在数据库里添加一些模拟的数据,并且保证UserRepository和CardRepository的正确性,同时还要保证D系统能正常工作,才能对B进行单元测试。这样显然是不合理的:假如我们的数据库服务器down掉了,我们的领导会在报告上看到B的单元测试通不过,会以为B有问题。

实际上,我们单元测试的环境不一定会有数据库和D系统,即使有,我们必须花费很大的代价去维护数据库与程序之间的一致性。假如我们的方法会往数据库里写数据,那么我们每次运行单元测试前还必须将数据库恢复到最初始的状态。

  • 假如我们有两种客户,一种使用数据库存储数据,另一种使用Excel存储数据;这样的话,要么要在Repository相关的类中进行这样的判断,要么在业务层中进行判断。

这样的坏处是,我们必须向每个客户提供这两种逻辑(万一有第三个客户要从别的系统取呢?);其次,Repository的每一个类也不得不进行这种逻辑判断。

  • B要负责管理C的实例对象。

B必须要知道如何生成C(即C的构造方法的参数列表),如果C的构造方式发生变化,不得不修改B中相关的所有代码。其次,例子中每访问一次这个方法,B就会生成其他三个类的实例。如果我们希望一个类是单例的,或者实例对象的数量要收到约束,那么不得不修改B或C的代码。

 

方案一完全被否定了,那么就再想一个方法吧。使用工厂+接口,这样乃就没话说了吧?

方案二:

        public bool ValidateCard(string cardId, string password)
        {
            IUserRepository user_repository = ClassFactory.CreateUserRepository();
            ICardRepository card_repository = ClassFactory.CreateCardRepository();
            IUserService user_service = ClassFactory.CreateUserService(ATMHelper.UserServiceAddress);

            Int64 user_id = user_repository.GetUserIdByCardId(cardId);
            if (user_id <= 0) return false;  //Not found in database

            user_service.OpenConnection();
            if (!user_service.ValidateUser(user_id))
                return false;

            string correct_password = card_repository.GetPassword(user_id);
            return correct_password == password;
        }

我们这里提供的例子是一个最简单的工厂,不过这样子倒是会有不少的帮助。

借助接口,我们已经把B层和C层完全剥离开。在我们为B写单元测试的时候,我们可以定义模拟的Repository,比如MockUserRepository,让它实现IUserRepository接口,我们在MockUserRepository里直接返回一些模拟数据(或者从XML读取一些模拟数据),这样子的话B就不会依赖与C以及数据库了:我们只需要写好ClassFactory的逻辑,就能达到单元测试的目的。

不过,这也有很多问题,具体实现中会逐渐遇到:

  • 工厂类会非常复杂。
  • 要进行模块替换时,需要重新编译整个项目文件。

可以看出,无论采用哪种工厂方法还是有一个共同的问题:我们的类还是会依赖于工厂类,还是必须编写程序来维护类的实例化过程和相关的依赖,而且这些依赖隐藏在工厂类的具体实现中,使得结构不清晰,也不利于维护。

使用术语来说,上面的这些实现方式都是一种“拉”(pull)的模式,在需要时我们从工厂中“创造”一个实例对象;为了使类之间的依赖完全消除,依赖注入采用的是“推”(push)模式,让其他的类(也就是依赖注入的框架)把依赖“注入”进来,我们完全不管如何实例化这些对象。下面是例子:

    public class ATM
    {

        private readonly IUserRepository _userRepository;
        private readonly ICardRepository _cardRepository;
        private readonly IUserService _userService;

        public ATM(IUserRepository userRepository, ICardRepository cardRepository, IUserService userService)
        {
            this._userRepository = userRepository;
            this._cardRepository = cardRepository;
            this._userService = userService;
        }

        public bool ValidateCard(string cardId, string password)
        {

            Int64 user_id = _userRepository.GetUserIdByCardId(cardId);
            if (user_id <= 0) return false;  //Not found in database

            _userService.OpenConnection();
            if (!_userService.ValidateUser(user_id))
                return false;

            string correct_password = _cardRepository.GetPassword(user_id);
            return correct_password == password;
        }

    }

这种情况下,依赖注入就突现出它的作用了。

这里我写了一个最简单的范例,支持向接口注册类(单例或非单例)的具体实现。这只是一个很简单的小范例,它只能支持默认构造方法,对于多层依赖只能通过属性注入的方式实现。由此可以看出依赖注入的框架编写起来并不简单,因此在企业中通常是使用现成的成熟的框架。

using System;
using System.Collections.Generic;
using System.Collections.Concurrent;
using System.Linq;
using System.Reflection;
using System.Text;

namespace CommonTools
{

    /// <summary>
    /// Provides simple factory to create new instance of registered interface, or get the singleton instance.
    /// </summary>
    public class IocClassFactory
    {

        //This dictionary stores registered interface type and singleton object.
        private ConcurrentDictionary<Type, InternalClassReferences> _classReferences;

        private static object _lockObject = new object();

        private static Type[] _emptyParameterTypes = { };

        private static Object[] _emptyParameterObjects = { };

        //This class itself is singleton
        private static IocClassFactory _instance;

        /// <summary>
        /// Gets the unique instance of IocClassFactory.
        /// </summary>
        public static IocClassFactory Instance
        {
            get
            {
                lock (_lockObject)
                {
                    if (_instance == null)
                        _instance = new IocClassFactory();

                    return _instance;
                }
            }
        }

        private IocClassFactory()
        {
            this._classReferences = new ConcurrentDictionary<Type, InternalClassReferences>();
        }

        public void RegisterInterface<T, R>() where R : class, new()
        {
            RegisterInterface<T, R>(false);
        }

        public void RegisterInterface<T, R>(bool m_isSingleton) where R: class, new()
        {
            System.Type t = typeof(T);

            if (this._classReferences.ContainsKey(t))
            {
                lock (_lockObject)
                {
                    InternalClassReferences reference = this._classReferences[t];

                    reference.IsSingleton = m_isSingleton;
                    this._classReferences[t] = reference;
                }
            }
            else
                this._classReferences.TryAdd(t, new InternalClassReferences(m_isSingleton, typeof(R)));
        }

        public void RemoveInterface<T>()
        {
            InternalClassReferences reference;

            this._classReferences.TryRemove(typeof(T), out reference);
        }

        /// <summary>
        /// Gets the instance of the T interface type. Depending on the RegisterInterface method, returns a new object or existing singleton object.
        /// </summary>
        /// <typeparam name="T">The type of the interface to resolve.</typeparam>
        /// <returns>A new instance of existing instance of T interface.</returns>
        public T Resolve<T>() where T : class
        {
            System.Type t = typeof(T);

            if (this._classReferences.ContainsKey(t))
            {
                lock (_lockObject)
                {
                    InternalClassReferences reference = this._classReferences[t];

                    if (reference.IsSingleton)
                    {
                        if (reference.SingletonObject != null)
                            return (T)reference.SingletonObject;
                        else
                        {
                            ConstructorInfo constructor = reference.Constructor;
                            T instance = (T)constructor.Invoke(_emptyParameterObjects);

                            reference.SingletonObject = instance;
                            this._classReferences[t] = reference;

                            return instance;
                        }
                    }
                    else
                    {
                        ConstructorInfo constructor = reference.Constructor;

                        Object new_object = constructor.Invoke(_emptyParameterObjects);
                        //reference.Objects.Add(new_object);

                        return (T)new_object;
                    }

                }
            }
            else
                throw new ArgumentException("The interface or type has not been registered.", t.Name);
        }

        internal class InternalClassReferences
        {
            public bool IsSingleton;
            public object SingletonObject;
            public System.Type RegisteredType;
            public ConstructorInfo Constructor;

            public InternalClassReferences(bool m_isSingleton, Type m_registeredType)
            {
                this.IsSingleton = m_isSingleton;
                SingletonObject = null;
                RegisteredType = m_registeredType;

                System.Type[] array = {};

                Constructor = m_registeredType.GetConstructor(array);

                //if (m_isSingleton)
                //    Objects = null;
                //else
                //    Objects = new List<object>();
            }
        }

    }
}

 

使用这个类,我们可以使用代码将具体的类型绑定到接口,比如:

IocClassFactory.Instance.RegisterInterface<IUserRepository, UserRepository>();

在需要这个接口的实例对象时,使用下面的代码就行了:

            IUserRepository user_repository = 
                IocClassFactory.Instance.Resolve<IUserRepository>();

依赖注入的具体内容在这个系列的下一篇日志中说明。

2条评论


  1. 先mark,最近要独立改某个模块,应该会用得着。
    提两点意见:
    1.这种系列式的文章,最好给一个前部分的ref
    2.现在blog字体过于大了,阅读起来不方便

    Google Chrome 33.0.1750.154 Google Chrome 33.0.1750.154 Windows 7 x64 Edition Windows 7 x64 Edition
    回复

  2. 阅。某些C#代码细节没看懂,不过大体思路是看明白了。

    看完后发现这个是上一个月发的…

    Google Chrome 33.0.1750.154 Google Chrome 33.0.1750.154 Windows 7 x64 Edition Windows 7 x64 Edition
    回复

发表评论

电子邮件地址不会被公开。