小编edv*_*dig的帖子

抽象

在过去的几个月里,我一直在编写一个轻量级,基于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时,上面列出的问题的可能解决方案.