程序中类之间共享值的技术

我们将构造函数注入一个类型为 IMyAppConfig 这只是一个包装所有这些东西。

我从未见过创建静态类 Environment 对于我自己的项目,当有足够强烈的需求时。

MyAppEnvironment.ApplicationFolder

如果使用注入传递值,那么您要么创建一个类来保存该值,要么b)传递一个字符串。后者不好,因为你的值应该是常数。前者是有效的,但似乎是一个公平的开销,因为只有一个有效值(如果您真的需要,您仍然可以在测试中模拟/伪造该值)。

我想你可以注入你的环境类,但对我来说这似乎是过分了。

看起来你的应用程序中有一个全局设置。使用aop o构造函数注入来传递这种依赖性似乎有点过头了,因为一个更简单的解决方案可以做到这一点。

我在这里的首选是对静态类使用静态属性。我将添加一个特定的写例程来防止多个集合。例如。。。

public static class GlobalSettings {
  private static string s_path;
  public static string Path { get { return s_path; } }
  public static void UpdatePath(string path) {
    if ( s_path != null || path == null ) { throw ... }
    s_path = path;
  }
}

如果你有一个标准的.NET应用程序,你应该已经有了一个设置类。您可以创建一个新的设置并将该值设置为默认值左右。

我总是问这样的问题:什么样的事情可以改变?当这些事情发生变化时,什么会产生最小的痛苦?哪些部分可以在其他系统中重用,如何将重用的痛苦降到最低?基本上,这些东西怎么能尽可能地分离呢?

考虑到这一点,答案实际上是基于您正在开发的系统的细节。

在任何使用此路径的过程中,我都可能将其作为参数传递下去。这将从启动路径使用的任何操作开始。每个方法都应该“做好一件事”,如果路径是这件事的一部分,那么它应该是一个参数。在发起操作的类中(以及在控制该类生存期的任何类中,等等),我可能会将路径作为构造函数的一部分。

这是我过去用过的方法,对我很有用。例如,在一个应用程序中,我采用了这种方法,后来发现需要允许用户更改路径设置。通过遵循这种体系结构(并避免使用单一路径),已经使用该路径的对象可以继续使用旧路径而不会出错,但从更改的角度来看,新路径使用正确。只是起作用了。

并且类可以迁移到一个新项目中,而不依赖于这个特定的细节。