【问题标题】:Is it possible to make an instance of a non-static class available to an entire WPF application?是否可以使整个 WPF 应用程序可以使用非静态类的实例?
【发布时间】:2014-03-23 15:28:08
【问题描述】:

我有一个 WPF 应用程序,它包含一个 MainWindow,以及可以通过 MainWindow 访问的各种 Page 对象。我目前在MainWindowViewModel 中实例化了一个User 类,它定义了绑定到相应View 中的各种属性的权限属性:

public NavigationViewModel()
{
    _currentUser = new User(_currentServerConnection, Environment.UserName);

现在,我想在每个Page 对象的ViewModels 中访问同一个User 实例。从设计的角度来看,最合适的方法是什么?我已经阅读了 StackOverflow 上的多个线程,并得出的结论是我应该创建这个类 static(这里没有意义,这个类有一个 state),或者在每个 ViewModel 中实例化它.还有其他我可能会错过的选择吗?哦,我也读过关于单例类的文章,这显然是不建议的。我觉得我在这里遗漏了一些基本概念。

【问题讨论】:

  • 不建议使用单身人士。建议不要在错误的地方或错误的方式使用单例。您的整个问题都在尖叫是何时使用单例的“正确”和“正确”示例。
  • 静态和单例之间的唯一区别是单例在第一次使用之前不会被实例化。单例也可以在多线程应用程序中正常工作。带锁msdn.microsoft.com/en-us/library/ff650316.aspx
  • 您也可以混合使用 IOC 和 Singleton 模式。您创建一个接口。您创建一个实现该接口的 Singleton。然后你的 IOC 控制器/工厂每次都使用你的单例。
  • @Rhyous 在阅读了您最初的评论后,我决定投入更多时间研究单例及其用途。由于功能和简单性,这似乎是我想要走的路线。现在,很抱歉获得元数据,但似乎没有任何方法可以将您的评论标记为“答案”。我应该在这里做什么?谢谢!
  • 我可以将我的 cmets 移动到一个答案。

标签: c# wpf mvvm view viewmodel


【解决方案1】:

不建议使用单身人士。建议不要在错误的地方或错误的方式使用单例。

您的整个问题都在尖叫是什么时候最好使用单例的“正确”和“正确”示例。

如果您绘制设计图并且代码中的大量对象指向另一个对象的完全相同的实例,并且不需要该对象的第二个实例,那么您已经找到了单例的正确用途。根据你的描述,你就是这种情况。

现在,您还可以使用静态。静态和单例之间的唯一区别是单例在第一次使用之前不会被实例化。由于您可能在加载后进行了登录,因此您不妨等到第一次登录尝试发生后才实例化您的单例。所以这就是为什么你会使用单例而不是静态的。

public class GlobalSettings : IGlobalSettings
{
    public static GlobalSettings Instance
    {
        get { return _Instance ?? (_Instance = new GlobalSettings()); }
    } static GlobalSettings _Instance;

    public GlobalSettings() 
    {
    }

    // More methods/properties here
}

单例也可以在带锁的多线程应用程序中正常工作。见这篇文章:http://msdn.microsoft.com/en-us/library/ff650316.aspx

单例也很容易在 IOC 中进行单元测试或使用。任何说其他话的人都没有意识到您可以简单地使用接口来描述单例,然后所有使用单例的对象都可以拥有该接口的实例。我使用惰性属性注入,如下所示,除非 IOC 库已经到位。我不会仅仅为此而包含 IOC 库的膨胀。

    public static IGlobalSettings Settings
    {
        get { return _Settings ?? (_Settings = GlobalSettings.Instance); }
    } static IGlobalSettings _Settings;

或者您也可以让您的 IOC 控制器/工厂每次都返回您的单例实例作为您的接口。

【讨论】:

    【解决方案2】:

    在所有视图模型中拥有任何共享数据的最简单方法是在公共基类中声明这些属性。如果您的所有视图模型都扩展了这个基类,那么它的属性将可供所有人使用。

    如果您想要更深入一点,您可以拥有一个实现单例模式的类,以确保只有一个实例。我有一些大型 WPF 应用程序,它们的基本视图模型提供对许多 ...Manager 类的访问,这些类为所有扩展视图模型提供各种服务。

    其中之一是StateManager 类,它实现了单例模式并且基本上拥有整个应用程序中常见的所有属性。这是暴露它的基类的属性:

    public StateManager StateManager
    {
        get { return StateManager.Instance; }
    }
    

    这就是我在 UI 中使用它的方式:

    <RadioButton IsChecked="{Binding StateManager.SomeValue}" Content="all" />
    

    【讨论】:

      【解决方案3】:

      另一种方法是使用管理对象的创建和生命周期的东西,例如inversion of control container

      如果您决定探索这种方法,您需要做的就是:

      1. 在您的应用程序 (composition root) 中有一个入口点,您可以在其中告诉容器哪些对象以及如何可用(在 WPF 中,这将是 App
      2. 设计你的类,以便它们可以利用依赖注入(即你的视图模型不会创建用户实例,而是期望它将通过提供构造函数注入)
      3. 不再担心视图模型代码中的对象生命周期(它不应该在视图模型职责范围内)

      Autofac 为例:

      // App.xaml.cs
      var builder = new ContainerBuilder();
      builder.RegisterType<User>()
          .WithParameter("userName", Environment.UserName)
          // tell container only one instance of this object should be ever created
          .SingleInstance();
      
      
      // ViewModel.cs
      public ViewModel(User user)
      {
          // we don't care at this point whether user is single instance or not;
          // it's container's responsibility to handle it for us
          this.user = user;
      }
      

      将当前服务器连接注入用户可能会出现问题(因为它在组合根设置中不可用),但只需使用 factory method pattern 就足以解决此问题。

      【讨论】:

        【解决方案4】:

        这有点取决于User 和各种视图模型之间的关系。

        一种方法是,如果有一个逻辑 User 实例,并且所有视图模型都反映了这个单个用户的状态。在这种情况下,我认为最合乎逻辑的路径是在所有视图模型之间传递一个 User 实例。

        假设您的代码是单线程的,单例模型在这里也可以很好地工作。但是我通常反对在可变对象上使用这种模式。今天你的应用程序是单线程的,明天可能不是。很容易忘记你在一周或一年后做出了这个关键假设,最终把自己置于一个非常糟糕的境地

        另一方面,如果每个视图模型都有不同的逻辑User 实例,那么每次都创建一个新实例。

        【讨论】:

          【解决方案5】:

          使用静态类和静态字段是一种方法。

          另一种方法是将用户类对象作为参数传递给页面视图模型的构造函数。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 2017-03-17
            • 2014-12-31
            • 1970-01-01
            • 1970-01-01
            • 2020-12-13
            • 2012-05-25
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多