3

我在用着

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

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

我需要确保：

  • 路径一旦设置就不会被意外更改
  • 需要它的类可以访问它。

我考虑过：

  • 使其成为单例
  • 使用构造函数依赖注入
  • 使用属性依赖注入
  • 使用 AOP 在需要的地方创建路径。

每个都有优点和缺点。

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

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

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

AOP 看起来很有希望，我正计划使用 AOP 进行日志记录，所以这至少听起来像是一个简单的解决方案。

还有其他我没有考虑过的选择吗？我对我所考虑的选项的评估是否偏离了基础？

4

5 回答 5

3

Environment当有足够强烈的需求时，我从未见过像为我自己的项目创建静态类那样的问题。

MyAppEnvironment.ApplicationFolder

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

我想你可以注入你的环境类，但对我来说这似乎有点矫枉过正。

于 2010-03-17T16:31:46.897 回答
1

看起来您拥有的内容相当于应用程序中的全局设置。使用 AOP 或构造函数注入来传递此依赖项似乎有点矫枉过正，因为更简单的解决方案可以解决问题。

我的偏好是在静态类上使用静态属性。我会添加一个特定的写入例程来防止多个集合。例如 ...

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;
  }
}
于 2010-03-17T16:34:51.040 回答
0

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

于 2010-03-17T16:29:16.283 回答
0

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

于 2010-03-17T16:34:08.997 回答
0

我的过程是总是问这样的问题：什么样的事情可以改变？当这些事情发生变化时，什么会产生最少的痛苦？哪些部分可以在其他系统中重用，如何将重用的痛苦降到最低？基本上，这些东西如何尽可能地解耦？

考虑到这一点，答案实际上取决于您正在处理的系统的详细信息。

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

这是我过去使用的方法，它对我很有帮助。例如，在一个应用程序中，我采用了这种方法，后来发现需要允许用户更改路径设置。通过遵循这种架构（并避免使用单例），已经使用路径的对象可以继续使用旧路径而不会出错，但是从更改点开始正确使用新路径。它刚刚奏效。

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

于 2010-03-17T16:44:18.270 回答