我需要一个模式对话框来收集一些用户输入。然后,我需要应用程序 MainFrame 使用相同的数据。
通常我的模态对话框会有一个指向某个 DataType 的指针,它能够存储我需要的内容,并且我会通过 MainFrame 的引用传递这个对象,以便能够在用户关闭模态对话框后恢复数据。
这是传递数据的最佳方式吗?
感觉不太对!
我需要一个模式对话框来收集一些用户输入。然后,我需要应用程序 MainFrame 使用相同的数据。
通常我的模态对话框会有一个指向某个 DataType 的指针,它能够存储我需要的内容,并且我会通过 MainFrame 的引用传递这个对象,以便能够在用户关闭模态对话框后恢复数据。
这是传递数据的最佳方式吗?
感觉不太对!
因为一旦用户关闭了对话框(大概是在 DialogResult.OK 上),您正在传递数据,您可以轻松地执行此操作而无需 MainFrame 引用。
因此,假设您的对话框中有一个名为 userNameTextBox 的 TextBox 和一个以 OK 结果结束对话框的按钮。您可以将 userNameTextBox 设为公开(不推荐)或添加属性以返回文本。
public string UserName
{
get { return userNameTextBox.Text; }
}
要在对话结束后获取此值,您只需执行以下操作:
Dialog dialog = new Dialog();
if (dialog.ShowDialog() == DialogResult.OK)
{
string username = dialog.UserName;
}
从用户那里收集一两个值时,@Samuel 的建议是完全足够的。
如果您获得许多值,那么您问题中的解决方案也很好。
不要成为过早优化和过度设计解耦解决方案的牺牲品。通过边界对象,我假设您指的是大型机和对话框引用的数据结构实例。对话框和大型机都引用这个对象有什么问题?在这种情况下解耦边界/传输对象有什么好处?
我在这里可以看到的唯一解耦收益是将大型机与向其提供数据的特定实现解耦。因此,不是大型机实例化 Dialog 并调用 Dialog.ShowModal,依赖注入将为大型机提供一个 IDataYouNeedGetter(这恰好是同一个模态对话框),并且在适当的时候大型机会这样做
myGetter.SetTransferObject(dataStructInstance)
myGetter.GoGetTheData()
// do stuff with dataStructInstance now that myGetter set it up.
但是,除非您已经知道解耦的特定需求,否则没有理由添加间接层。
通常您可以使用单个类或其他数据类型来传输数据。所以对话框是用来改变类的属性的。为什么感觉不对?
[幽默] 对于大型机,我认为您指的不是大型旧计算机(尽管还活着并且还在运转)。否则,我认为 TCP/IP 将是一个不错的选择。[/幽默]
执行此操作的最佳方法是将数据打包到事件中并在事件总线上发送出去。
这将对话框与大型机分离 - 如果您正确设计事件,它不会限制您仅使用对话框。
根据语言和环境的不同,这个事件系统可以很容易且廉价地实现。我称我的版本类为基于对象间通信。