相关疑难解决方法(0)

我理解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容器来解决这些依赖关系并在需要时构建实体是不好的做法吗？是否有可能做到这一点？

感谢您的任何见解.

抽象

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

设计挑战

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

依赖注入

出于多种原因,我选择采用DI方式.最明显的一个是可测试性,通过对接口进行编程并具有通过构造函数提供给它们的每个类的所有依赖关系,这些类很容易测试,因为测试容器可以实例化所需的服务或它们的模拟,并输入到每个要测试的课程.进行DI/IoC的另一个原因是,不管你信不信,提高代码的可读性.没有更多的初始化过程实例化所有不同的服务,并通过引用所需服务手动实例化类.配置内核(NInject)/注册表(StructureMap)可以方便地为引擎/游戏提供单点配置,其中选择和配置服务实现.

我的问题

• 我经常觉得我正在为接口创建接口
• 我的工作效率急剧下降,因为我所做的只是担心如何以DI方式做事,而不是快速简单的全局静态方式.
• 在某些情况下,例如在运行时实例化新实体时,需要访问IoC容器/内核来创建实例.这会产生对IoC容器本身的依赖(SM中的ObjectFactory,Ninject中的内核实例),这实际上违背了首先使用它的原因.怎么解决这个问题？我想到了抽象工厂,但这进一步使代码复杂化.
• 根据服务要求,某些类的构造函数可能变得非常大,这将使该类在其他情况下完全无用,如果不使用IoC.

基本上做DI/IoC会大大降低我的工作效率,在某些情况下会进一步使代码和架构复杂化.因此,我不确定这是一条我应该遵循的道路,还是只是放弃并以老式的方式做事.我不是在寻找一个单一的答案,说明我应该或不应该做什么,而是讨论从长远来看使用DI是否值得,而不是使用全局静态/单一方式,可能的优点和缺点我忽略了处理DI时,上面列出的问题的可能解决方案.