使用 Prism (CAL) 在当地范围内举办综合活动

发布于 2024-08-24 20:30:08 字数 307 浏览 2 评论 0原文

我开始用一个小型应用程序训练 Prism (CAL),并遇到了一些问题。

我正在创建 MainView 的多个实例,它本身包含一些区域,并将它们显示在 Shell 中。 我正在使用本地范围的区域来轻松处理 MainView 中的视图注入。

目前我正在寻找 MainView 内视图(viewModels)之间的通信方式。复合事件可以做到这一点,但是当我发布这些事件时,它们会在我的 MainView 的所有实例中处理,这是我真的不想要的。

有没有办法像本地范围的区域一样引发“本地范围的”复合事件?或者在我的情况下,可能有更好的方式在视图之间进行交流?

I'm starting to train Prism (CAL) with a small application and faced some problems.

I'm creating multiple instances of my MainView, which itself contains some regions, and display them in the Shell.
I'm using locally scoped regions to easily handle view injections within my MainView.

Currently I'm searching for a way of communication between the views (viewModels) inside the MainView. Composite events could do it, but when I publish those events, they are handled in all instances of my MainView, which I really don't want.

Is there a way of raising "locally scoped" composite events like with locally scoped regions? Or may be there's a better way of communicating between views in my case?

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

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

发布评论

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

评论(3

梦在深巷 2024-08-31 20:30:08

还可以创建本地范围的 EventAggregator 并在 MainView 中创建的子 UnityContainer 中注册(在创建本地范围区域的同一位置)。

恕我直言,这相当于局部范围的区域。

It's also possible to create locally scoped EventAggregator and register in a child UnityContainer, created in the MainView (at the same place, where locally scoped region is created).

This is an equivalent to a locally scoped regions imho.

少女的英雄梦 2024-08-31 20:30:08

将表单发送者作为参数传递。 (无论如何,必须有一种方法来区分您的应用程序的窗口 - 使用它。)当您收到事件时,检查当前表单ReferenceEquals to sender(或者检查表单“key”)。

Pass form sender as an argument. (Anyway, there must be a way to distinguish your application's windows - use it.) When you recieve the event, check whether current form ReferenceEquals to sender (Or, check the form 'key').

最笨的告白 2024-08-31 20:30:08

经过多次讨论,选择了EventAggregator。与其他人分享,以防他们处于相同的情况,我们的思维过程可能会帮助他们:(

问题陈述:请参阅我之前的评论)

主视图(ViewModel),它具有保存来自其他模块的视图的区域,并且也形成 TabItem视图负责清理自身及其包含的子视图。因此,在 TabItem 关闭事件中,此主视图 (ViewModel) 应通知其子视图正常关闭。

EventAggregator 和 .Net Eventing 都作为发送关闭消息的潜在候选者从各个方面进行了彻底的探索。

由于在 Prism 解耦环境中,主视图在技术上应该不知道其子视图,反之亦然,因此选择了 EventAggregator。

事件聚合器的一个问题是它向整个应用程序发布事件,但我们的要求是过滤来自关闭的 tabitemview 的事件。 EventAggregator 被设计为使用过滤器来验证关闭请求是否来自同一个 tabitemview(我们对每个 tabItem 使用作用域区域管理器,并且此作用域区域管理器用作过滤器),然后才执行关闭操作。这可确保在一个选项卡中触发关闭不会关闭恰好具有相同区域名称的其他选项卡中的子视图。

谢谢,
RDV

After much discussion, EventAggregator was selected. Sharing with other in case they are in the same situation and our thought process might help them:

(Problem statement: Refer to my previous comment)

The main View (ViewModel) which has regions to hold views from other modules and which also forms the TabItem view is responsible for cleaning up itself and child views it contains. Hence on TabItem closing event this main View (ViewModel) should inform its child views to gracefully shutdown.

Both EventAggregator and .Net Eventing were thoroughly explored from various aspects as potential candidate for sending the shutdown message.

Since, in a Prism decoupled environment the main View should be technically unaware of its child Views and vice versa, EventAggregator was chosen.

One issue with event aggregator is that it publishes events to whole application, but our requirement was to filter events coming from the tabitemview being closed. The EventAggregator was designed to use a filter to verify if the shutdown request is coming from the same tabitemview (we used scoped regionmanager for every tabItem and this scoped regionmanager was used as the filter) only then it executes the shutdown action. This ensures that triggering shutdown in one tab does not close child views in other tabs which happen to have the same regionname.

Thanks,
RDV

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