Question

我正在使用

Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + "\MyProgram"

作为存储我的程序使用的多个文件的路径。我想避免在我的应用程序中粘贴相同的代码片段。

我需要确保：

路径设置后不能意外更改
需要它的类可以访问它。

我考虑过：

使其成为单身人士
使用构造函数依赖注入
使用属性依赖注入
使用AOP创建所需的路径。

每个人都有利弊。

单身人士是每个人最喜欢的鞭打男孩。我并不反对使用它，但如果可能的话，有充分的理由避免使用它。

我已经大量使用Castle Windsor的构造函数注入了。但这是一个路径字符串，Windsor不能非常优雅地处理系统类型依赖关系。我总是可以将它包装在一个类中，但这对于像传递字符串值这样简单的东西来说似乎有些过分。在任何情况下，此路由都会为使用它的每个类添加另一个构造函数参数。

在这种情况下，我在属性注入中看到的问题是，从设置值到需要值的位置存在大量间接。我需要很长的中间人才能到达所用的所有地方。

AOP看起来很有前景，我打算使用AOP进行日志记录，所以这至少听起来像一个简单的解决方案。

我还没有考虑过其他选择吗？我是否根据我对所考虑的选项的评价而离开了基地？

Answer 1

我从来没有看到过为我自己的项目创建一个像Environment这样的静态类时遇到的问题，当时有足够强烈的需求。

MyAppEnvironment.ApplicationFolder

如果您使用注入传递值，那么您要么a）创建一个类来保存值，或者b）传入一个字符串。后者很糟糕，因为你的价值应该是不变的。前者是有效的，但似乎是一个公平的开销，因为只有一个有效值（如果你真的需要，你仍然可以模拟/伪造测试值）。

我想你可以注入你的环境类，但对我来说这似乎有些过分。

Answer 2

您的应用程序中的全局设置似乎相似。使用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;
  }
}

Answer 3

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

Answer 4

我们会在构造函数中注入一个类型IMyAppConfig的类，它只是所有这类东西的包装器。

Answer 5

我的过程总是提出这样的问题：什么样的事情可以改变？当这些事情发生变化时，会产生最少的痛苦是什么？哪些部分可以在其他系统中重复使用，以及如何最大限度地减少重用的痛苦？基本上，这些东西怎么能尽可能地分离呢？

考虑到这一点，答案实际上是基于您正在处理的系统的细节。

在使用此路径的任何进程中，我都可能将其作为参数传递给它。这将从任何启动路径使用的操作开始。每个方法应该“做好一件事”，如果路径是那个东西的一部分，那么它应该是一个参数。在启动动作的类中（以及在任何类中控制该类的生命周期等），我可能会将路径作为构造函数的一部分。

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

这些类可以迁移到一个新项目，而不依赖于这个特定的细节。

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

5 个答案: