如何跟踪所有消息
视图模型之间的松耦合通信是一个很好的概念。 我使用过 Prism Eventaggregator 以及 MVVM Light Toolkit 的 Messenger。
如果项目发展，我会收到很多来回消息。
跟踪我的消息的最佳做法是什么？命名约定？模式？ ETC... 你如何跟踪？
loosly coupled communication between viewmodels is a nice concept.
I have used Prism Eventaggregator as well as MVVM Light Toolkit's Messanger.
If the project grows I get alot of messages back and forth.
What is best practise of keeping track of my messages? Naming conventions? patterns?
etc...
How do you keep track?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我发现提供包含强类型消息的“消息”命名空间有很多价值。请记住，定义良好的消息将更像合同/DTO - 您希望保持尽可能多的解耦，因此依赖性应保持在最低限度，否则发送者和接收者都将依赖于公共库。有时，由于消息的性质，这是必要的。
我想您还会发现许多消息可能遵循特定的模式。我将两种常见的消息模式称为“操作”和“命令”。动作更多的是“动词”和“主语”。
例如，您可能有公开 T Target 的 MessageAction，并且操作是一个枚举，指示更新、选择、添加、删除等。这是常见的，通用消息可以包装它，并且您的处理程序侦听关闭 T Target 的泛型。他们感兴趣的类型。
命令是源自某处的操作，然后将操作应用于目标。例如，也许您正在向用户添加角色。在这种情况下，您感兴趣的项目是角色，您的目标是用户，您的操作是添加它。这可以是一个 CommandAction。
组织消息的另一种常见方法是实现公共接口或基类。这样，在项目中搜索实现者以确定消息的使用位置就变得很简单了。
I've found that there is a lot of value in providing a "Messages" namespace that contains your strongly typed messages. Keep in mind that well-defined messages will be more like contracts/DTOs - you want to maintain as much decoupling as possible, so dependencies should be kept to a minimum, otherwise the senders and receivers will both rely on common libraries. Sometimes this is necessary due to the nature of the message.
I think you'll also find that many messages may follow a particular pattern. Two common message patterns are what I'll call the Action and Command. Action is more of a "verb" and a "subject".
For example, you might have MessageAction that exposes T Target, and the action is an enumeration that indicates update, select, add, delete, etc. That's common and a generic message can wrap it, and your handlers listen for the generics that close the type they are interested in.
The Command is an Action that originates from somewhere and then applies an action to a target. For example, maybe you are adding a role to a user. In that case, your item of interest is the role, your target is the user, and your action is adding it. That can be a CommandAction.
Another common way to organize messages would be to implement a common interface or base class. It then becomes trivial to search for implementors in the project to determine where messages are being used.
好问题。以下是我一直在使用的解决方案，但可能有很多替代方案，但尚未找到任何相关指导。
一种方法是定义扩展基本事件的特定事件：使用 prism 时的典型示例是 CompositePresentationEvent 的扩展。
但是，当拥有大量消息时，有时定义什么是消息很有用。通常它可以由消息头、一些消息属性和实际内容来定义。然后你可以将这些消息放入你的消息总线中。
Good question. Here are the solutions I've been using, but there are probably a lot of alternatives and haven't found any guidance on that.
One way is to define specific events that extend basic events : typical example when using prism is an extension of CompositePresentationEvent.
However, when having a large number of messages, it's sometimes useful to define what is a message. Usually it can be defined by a message header, some message attributes and an actual content. Then you can put these messages into your messagebus.