摘要

在过去的几个月里，我一直在使用 API 抽象和实体/组件/脚本系统编写一个基于 C# 的轻量级游戏引擎。它的整个想法是通过提供类似于 Unity 引擎的架构来简化 XNA、SlimDX 等中的游戏开发过程。

设计挑战

大多数游戏开发人员都知道，您需要在整个代码中访问许多不同的服务。许多开发人员求助于使用全局静态实例，例如渲染管理器(或 Composer )、场景、图形设备(DX)、记录器、输入状态、视口(viewport)、窗口等。全局静态实例/单例有一些替代方法。一种是通过构造函数或构造函数/属性依赖注入(inject)(DI)为每个类提供它需要访问的类的实例，另一种是使用全局服务定位器，例如 StructureMap 的 ObjectFactory，其中服务定位器通常配置为一个 IoC 容器。

依赖注入(inject)

出于多种原因，我选择采用 DI 方式。最明显的一个是可测试性，通过针对接口(interface)编程并通过构造函数向它们提供每个类的所有依赖项，这些类很容易测试，因为测试容器可以实例化所需的服务或它们的模拟，并输入每一门课都要考。不管你信不信，做 DI/IoC 的另一个原因是提高代码的可读性。不再需要庞大的初始化过程来实例化所有不同的服务，也不再需要引用所需服务来手动实例化类。配置内核(NInject)/注册表(StructureMap)可以方便地为引擎/游戏提供单点配置，在那里选择和配置服务实现。

我的问题

最佳答案

你应该回到老式的方式吗？
简而言之，我的答案是否定的。由于您提到的所有原因，DI 有很多好处。

I often feel like I am creating interfaces for interfaces sake

Depending on service requirements, some classes' constructors can get very large, which will make the class completely useless in other contexts where and if an IoC is not used.

In some cases, e.g. when instantiating new Entities on runtime, one needs access to the IoC container / kernel to create the instance. This creates a dependency on the IoC container itself (ObjectFactory in SM, an instance of the kernel in Ninject), which really goes against the reason for using one in the first place. How can this be resolved? Abstract factories come to mind, but that just further complicates the code.

new SomeBusinessObject(
    new SomethingChangedNotificationService(new EmailErrorHandler()),
    new EmailErrorHandler(),
    new MyDao(new EmailErrorHandler()));

public static class SomeBusinessObjectFactory
{
    public static SomeBusinessObject Create()
    {
        return new SomeBusinessObject(
            new SomethingChangedNotificationService(new EmailErrorHandler()),
            new EmailErrorHandler(),
            new MyDao(new EmailErrorHandler()));
    }
}

 SomeBusinessObject bo = SomeBusinessObjectFactory.Create();

public SomeBusinessObject()
{
    var errorHandler = new EmailErrorHandler();
    var dao = new MyDao(errorHandler);
    var notificationService = new SomethingChangedNotificationService(errorHandler);
    Initialize(notificationService, errorHandler, dao);
}

protected void Initialize(
    INotificationService notifcationService,
    IErrorHandler errorHandler,
    MyDao dao)
{
    this._NotificationService = notifcationService;
    this._ErrorHandler = errorHandler;
    this._Dao = dao;
}

SomeBusinessObject bo = new SomeBusinessObject();

public interface IDataAccessFactory
{
    TDao Create<TDao>();
}

public class ConcreteDataAccessFactory : IDataAccessFactory
{
    private readonly IocContainer _Container;

    public ConcreteDataAccessFactory(IocContainer container)
    {
        this._Container = container;
    }

    public TDao Create<TDao>()
    {
        return (TDao)Activator.CreateInstance(typeof(TDao),
            this._Container.Resolve<Dependency1>(), 
            this._Container.Resolve<Dependency2>())
    }
}

public class SomeOtherBusinessObject
{
    private IDataAccessFactory _DataAccessFactory;

    public SomeOtherBusinessObject(
        IDataAccessFactory dataAccessFactory,
        INotificationService notifcationService,
        IErrorHandler errorHandler)
    {
        this._DataAccessFactory = dataAccessFactory;
    }

    public void DoSomething()
    {
        for (int i = 0; i < 10; i++)
        {
            using (var dao = this._DataAccessFactory.Create<MyDao>())
            {
                // work with dao
                // Console.WriteLine(
                //     "Working with dao: " + dao.GetHashCode().ToString());
            }
        }
    }
}

Basically doing DI/IoC dramatically slows down my productivity and in some cases further complicates the code and architecture

关于c# - 依赖注入(inject)和开发生产力，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10313507/