在 MainFrame（或主对话框）和模态对话框之间传递数据的最佳方法是什么？
我需要一个模式对话框来收集一些用户输入。 然后，我需要应用程序 MainFrame 使用相同的数据。
通常我的模态对话框会有一个指向某些能够存储我需要的数据类型的指针，并且我将通过 MainFrame 的引用传递该对象，以便在用户关闭模态对话框后能够恢复数据。
这是传递数据的最佳方式吗？
感觉不对啊！
I need a modal dialog to gather some user input. I then need the same data to be consumed by the application MainFrame.
Usually my Modal Dialog would have a pointer to some DataType able to store what I need, and I'd be passing this object by reference from the MainFrame in order to be able to recover data once the modal dialog is closed by the user.
Is this the best way of passing around data?
It doesn't feel right!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
由于您在用户关闭对话框后（大概是在 DialogResult.OK 上）传递数据，因此您可以轻松地在没有 MainFrame 引用的情况下完成此操作。
假设您的对话框中有一个名为 userNameTextBox 的文本框，以及一个以 OK 结果结束对话框的按钮。 您可以将 userNameTextBox 公开（不推荐）或添加属性以返回文本。
要在对话框结束后获取该值，您只需执行以下操作：
Since you are passing data once the user has closed the dialog (presumably on DialogResult.OK), you can easily do this without having a MainFrame reference.
So say you have a TextBox on your dialog, called userNameTextBox and a button that ends the dialog with the OK result. You can either make the userNameTextBox public (not recommended) or add a property to return the text.
And to get this value after the dialog has ended, you just do:
当从用户那里收集一两个值时，@Samuel 的建议是完全足够的。
如果您获得很多值，那么您问题中的解决方案也很好。
不要陷入过早优化和过度设计解耦解决方案的境地。 通过边界对象，我假设您指的是大型机和对话框引用的数据结构实例。 对话框和主机都引用该对象有什么问题？ 在这种场景下，将边界/传输对象解耦有什么好处？
我在这里看到的唯一解耦回报是将大型机与向其提供数据的特定实现解耦。 因此，依赖注入不是由大型机实例化 Dialog 并调用 Dialog.ShowModal，而是为大型机提供 IDataYouNeedGetter（这恰好是相同的模式对话框），并且在适当的时候大型机会执行此操作，
但是没有理由添加间接层，除非您已经知道解耦的特定需求。
@Samuel's suggestion is perfectly adequate when collecting one or two values from the user.
If you're getting many values then the solution in your question is fine as well.
Don't fall prey to premature optimization and over-engineer a decoupled solution. By boundary object I assume you're referring to the datastructure instance referenced by the mainframe and dialog. What's the problem with the dialog and mainframe both referencing this object? What is the benefit of decoupling the boundary/transfer object in this scenario?
The only decoupling payoff I could see here would be decoupling the mainframe from the specific implementation that delivers the data to it. So rather than the mainframe instantiating Dialog and calling Dialog.ShowModal, dependency injection would provide the mainframe with an IDataYouNeedGetter (which would happen to be the same modal dialog) and at the appropriate time the mainframe would do
BUT, there is no reason to add a layer of indirection unless you already know of a specific need for the decoupling.
通常您可以使用单个类或其他数据类型来传输数据。 所以对话框是用来改变类的属性的。 为什么这感觉不对？
[幽默]
对于大型机，我认为您指的并不是大型旧计算机（尽管仍然活着并且运行良好）。 否则，我认为 TCP/IP 将是一个不错的选择。
[/幽默]
Normally you can use a single class or other datatype to transfer data. So the dialog is used to change the properties of the class. Why doesn't this feel right?
[humor]
With mainframe, I assume you don't mean the big old (althoug still alive and kicking) computers. Else, I think TCP/IP will be a good choise.
[/humor]
执行此操作的最佳方法是将数据打包到事件中并将其发送到事件总线上。
这将对话框与大型机分离 - 如果您正确设计事件，它不会限制您仅使用对话框。
根据语言和环境，该事件系统可以轻松且廉价地实现。 我将我的版本称为基于对象间通信。
The very best way of doing this is to package the data into an event and send it out on an event bus.
This decouples the dialog from the mainframe - and if you design the event properly it doesn't limit you to just using a dialog.
Depending on the language and environment this event system can be implemented easily and cheaply. I call my version class based interobject communication.