如何使用 MVVM、PRISM 和 MEF 在没有用户请求的情况下处理视图模型中的 UI 交互

发布于 2024-10-14 03:25:34 字数 1042 浏览 1 评论 0原文

我正在开发一个使用 WPF、MVVM、Prism 和 MEF 的应用程序。

我使用导航与请求导航的组合、使用区域管理器进行视图管理的控制器以及通过事件聚合器进行事件处理以在单个窗口中运行应用程序。我使用的视图优先方法类似于 Stock Trader RI 的工作方式。 当用户启动任何与 UI(繁忙指示器)交互的视图模型代码时,这种方法效果很好,但当它在幕后启动时,可能会出现问题。

我知道这看起来可能是一个糟糕的实现,但我认为我有一个有效的场景。我的具体示例与登录有关。

当前应用程序启动并加载 shell。登录视图被加载到 shell 的主要内容区域中。当用户单击“登录”时,会显示繁忙指示器并执行客户端应用程序服务登录。登录完成后,忙碌指示灯消失,屏幕导航至用户的主屏幕。

这很有效,因为导航登录和导航是由用户单击登录按钮发起的。

所以现在我有一个新的要求,用户可以在登录表单上选择自动登录,这样用户下次启动应用程序时,登录视图将不会显示,登录将在幕后发生。

现在,如果我只想调用自动登录功能,没有问题,它本身没有 UI 交互,并且可以正常工作。但登录需要几秒钟,我想显示我的忙碌指示器。

问题是我在哪里发起自动登录调用? shell视图模型构造函数? shell视图模型PartImportsSatisfied实现?在任何这些地方,shell 视图(其中包含我的忙碌指示器)尚未真正加载。因此,我所需的资源(例如区域和区域经理)均不可用。 那么对我来说实现这个的好方法是什么:

检查以前的用户是否应该自动登录(弄清楚这部分)

 If yes then
  Show busy indicator
  Attempt to auto login
  If auto login was success
   Hide busy indicator
   Navigate to user home screen
  Else
   Hide busy indicator
   Navigate to login screen
 Else
  Hide busy indicator
  Navigate to the login screen

任何想法都将不胜感激。

I am working on an application which is using WPF, MVVM, Prism, and MEF.

I am using a combination of navigation with request navigate, controllers with view management using region manager, and eventing via event aggregator to run the application in a single window. I'm using a view first approach similar to how the Stock Trader RI works.
This works great when any view model code that would interact with the UI (busy indicator) is kicked off by the user, but when it is started behind the scenes there can be problems.

I know this may seem like a poor implementation, but I think I have a valid scenario. My particular example has to do with login.

Currently the application starts and loads the shell. The login view is loaded into the main content region of the shell. When the user clicks "login" a busy indicator is shown and the client application services login is executed. When the login is complete, the busy indicator goes away, and the screen is navigated to the user's home screen.

This works well because the navigation login and navigation are initiated by the user clicking the login button.

So now I have a new requirement that a user can select Auto Login on the login form, such that the next time the user starts the app, the login view will not show up and login will happen behind the scenes.

Now if I just want to call the auto login feature, there is no problem, this by itself has no UI interaction and will work fine. But login takes a few seconds and I want to display my busy indicator.

The problem is where do I initiate the auto login call? The shell view model constructor? The shell view model PartImportsSatisfied implementation? In any of these places, the shell view (which contains my busy indicator) isn't really loaded yet. As a result, none of the resources I need, like regions and region managers aren’t available.
So what might be a good way for me to implement this:

Check if previous user should auto login (got this part figured out)

 If yes then
  Show busy indicator
  Attempt to auto login
  If auto login was success
   Hide busy indicator
   Navigate to user home screen
  Else
   Hide busy indicator
   Navigate to login screen
 Else
  Hide busy indicator
  Navigate to the login screen

Any ideas are greatly appreciated.

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

扫码二维码加入Web技术交流群

发布评论

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

评论(1

淑女气质 2024-10-21 03:25:34

在您的 ShellViewModel 中实现一个接口,它将处理可加载的概念。不要在 ShellViewModel 的构造函数中执行此逻辑,因为这通常是不好的做法,最多应用于实例化对象。

public class ShellViewModel : ILoadable
{
    public ShellViewModel()
    {

    }

    bool ILoadable.Load()
    {
         //this is where you can take care of your auto login
    }
}

然后,您可以在 Bootstrapper 类中调用它。如果这是在另一个模块中完成的,您可以在 IModule.Initialize 方法中调用它。

我还认为,这个逻辑应该在一个服务中实现,该服务可以由上面提到的 ShellViewModel 调用,或者理论上可以直接从 Bootstrapper 类调用;允许 ShellViewModel 潜在地使用服务内的状态数据。

Implement an interface within your ShellViewModel which will deal with the concept of being loadable. Do not perform this logic within the constructor of the ShellViewModel as this is typically bad practice and should be used to instantiate objects at the most.

public class ShellViewModel : ILoadable
{
    public ShellViewModel()
    {

    }

    bool ILoadable.Load()
    {
         //this is where you can take care of your auto login
    }
}

You could then call this within your Bootstrapper class. If this were being done within another module you could call it within the IModule.Initialize method.

I would also argue that this logic should get implemented within a service which could be called by the ShellViewModel as mentioned above or could in theory be called directly from the Bootstrapper class; allowing the ShellViewModel to potentially then make use of stateful data from within the service.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文