直接使用设置还是通过包装类？

发布于 2024-10-10 04:40:18 字数 1033 浏览 0 评论 0原文

参考 .NET 设置机制，并受到 this< 的几个答案的启发/a> 问题，似乎有些人主张通过另一个包装类（也许是单例）来包装 Settings 的使用。

Settings 类不是已经是单例了吗？

[global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
[global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "9.0.0.0")]
internal sealed partial class Settings : global::System.Configuration.ApplicationSettingsBase {

    private static Settings defaultInstance = ((Settings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new Settings())));

    public static Settings Default {
        get {
            return defaultInstance;
        }
    }
// rest of class...
}

.
.
.
那么，将 Settings 包装在另一个类中并执行此操作有什么好处：

int foo = MySettingsWrapper.MyInt;

而不是在需要时直接执行此操作：

int foo = Settings.Default.MyInt;

原文

With reference to the .NET Settings mechanism, and inspired by a couple of the answers to this question, it seems that some people advocate wrapping the use of Settings via another wrapper class, perhaps a singleton.

Isn't the Settings class a singleton already?

[global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
[global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "9.0.0.0")]
internal sealed partial class Settings : global::System.Configuration.ApplicationSettingsBase {

    private static Settings defaultInstance = ((Settings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new Settings())));

    public static Settings Default {
        get {
            return defaultInstance;
        }
    }
// rest of class...
}

.
.
.
So, what is the benefit of wrapping Settings in another class and doing this:

int foo = MySettingsWrapper.MyInt;

instead of doing this directly where needed:

int foo = Settings.Default.MyInt;

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

人生戏 2024-10-17 04:40:19

Settings 类本身并不是单例。你可以这样做：

var s1 = new Settings();
var s2 = new Settings();
var s3 = new Settings();

但是，我相信这不会给你带来多大好处，因为据我所知，s1、s2和s3的值都会保留在同一位置：

c:\Documents and Settings>\\[Local Settings\]Application Data\\__\< ;verison>\user.config

所以我怀疑：

s1.MyInt = 1;
s1.Save();

将与以下相同

s2.MyInt = 1;
s2.save();

因此，您将获得 Settings.Default 静态属性，该属性返回单个线程安全实例。我一直按原样使用它，看不出有任何理由要包装它。但是，您可能想要扩展它，例如，如果您想控制 user.config 的位置：如何使设计器生成的.Net应用程序设置可移植

The Settings class is not a singleton per se. You could do:

var s1 = new Settings();
var s2 = new Settings();
var s3 = new Settings();

However, I believe it won't do you much good, since AFAIK the values of s1, s2 and s3 will all be persisted in the same place:

c:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<verison>\user.config

So I suspect:

s1.MyInt = 1;
s1.Save();

will be the same as

s2.MyInt = 1;
s2.save();

For that reason, you get the Settings.Default static property, which returns a single, thread safe instance. I use it all the time as it is, don't see any reason to wrap it. However, you might want to extend it, for example if you wanted to control the location of user.config: How to make designer generated .Net application settings portable

回复收藏 0 原文