设置和保存这些“全局”对象的最佳做法是什么?
我用
几次遇到过这个问题ORM会话对象(来自DevExpress的XPO)
IOC容器(Microsoft.Unity)
记录器(来自The Object Guy)
我已经提出了三个如何解决这个问题的方法:
依赖注入。 这对我来说看起来非常麻烦,我觉得每个班级都会被额外的三个getter / setter臃肿,几乎所有类都会使用。另一方面,它消除了全局变量的恐惧,并使代码位相互依赖性降低。
创建一次可设置的静态类(例如ContainerKeeper)并返回保留的对象。我知道这类似于单身人士,我应该使用单身人士。
使用单一模式。 我已经阅读过一些关于单身人士使用情况以及他们有多糟糕等问题的讨论。所以我坦率地不确定在这些情况下我会使用一个优秀OO设计原则。
所以我的问题改为:
还有其他选择,我完全不在赛道上吗?你会怎么做?
答案 0 :(得分:2)
我通常使用依赖注入,这将是选项1.但是我通常使用属性而不是使用构造函数参数进行注入。这清理了我的构造函数。我使用Castle Windsor作为IoC容器。它允许我将设置代码从构造函数移动到Initialize方法,该方法在我实现IInitializable接口时设置所有依赖项后调用。但我的猜测是Unity也支持这样的东西。
选项2和3不是最佳选择。通过调用静态函数,您可以将代码绑定到它所依赖的类的实现。注入它们只会将代码绑定到依赖项的接口。
您确实需要容器对象。但通常只在最高级别。依赖关系的依赖等自动解决,城堡windsor做到这一点,我很确定团结也这样做。我通常不会将IoC容器用于需要动态构建的对象,因此我通常不需要在较低级别上引用容器。当我需要这个时,有一些技巧可以让容器将自身注入依赖它的类中。得写一篇关于此的博客文章。完成后我会通知你。
答案 1 :(得分:2)
我会把它们放在你自己设计的界面后面并调用全局实例。这样你就不会受那个特定实现的束缚。您清楚地定义了这些服务正在使用的内容。最后避免弄乱那些类。
就像判断一样。确保您所创造的全球化是真正的全球服务。例如,Logger绝对是一个很好的候选人。