时间：2019-01-17 标签：c#formscommunication
我有一个 C# 应用程序，由 3 个表单组成：
1：战舰游戏 GUI 2：网络 GUI（进行客户端/服务器连接） 3：聊天图形界面
首先加载表格 1。当用户选择设置网络时，将显示表格2。
当用户选择发送聊天或收到聊天时显示聊天。
我希望 Form 2 处理所有消息并将相关消息传递到相关 GUI 以进一步解码消息。
我仍处于发展的早期阶段。目前，我尝试使用委托在表单之间进行通信。
这是最好的方法吗？关于应用程序组件相互发送消息的最佳实践是什么？
I have a C# application which consists of 3 forms:
1: Battleship Game GUI 2: Network GUI (does client/server connections) 3: Chat GUI
Form 1 is loaded first. When the user selects setup network, Form 2 is displayed.
Chats are displayed when the user opts to send a chat or when a chat is received.
I would like Form 2 to process all the messages and pass on the relevant messages to the relevant GUI to decode the message further.
I'm still at an early stage of development. At the moment I am trying to use delegates to communicate between the forms.
Is this the best way of doing this? What are the best practices regarding components of an application sending messages to each other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
ikurts，这绝对不是一个好的做法。无论您的用户界面有多少，都应该与通信完全无关。您应该：
听起来您想在设置时遵循最佳实践你的应用程序。我想你会得到很多关于这个问题的反馈，所有这些反馈听起来都是这样的。帮自己一个忙并遵循它。并远离表单中的通信逻辑！
还有一些想法：
我不知道为什么你想把它分成三个屏幕，而两个屏幕看起来合乎逻辑：1）网络设置对话框2）游戏对话框可以容纳战舰UI和你的聊天界面。此配置还将简化您的结构，因为只有一个屏幕，即游戏/聊天屏幕需要更新。设置对话框就是这样。
以下是 CodeProject 上的线程聊天应用程序 的示例，该应用程序可以很好地作为代码基础开始。我想你的战舰移动只是“特殊”聊天消息，指定棋盘命中。
另外，这里有一个网络启用的井字棋游戏的示例，可能会产生有关开发客户端/服务器游戏的线索。
不要回避看似困难的事情！我的建议是首先编写一个没有 UI 的聊天/通信客户端，也许只有控制台输出。然后添加一个屏幕，您将发现不必将窗口与网络内容结合起来。
祝你好运！
更多链接：
这是一个很好的 有关 MVC/MVP 的讨论可能会对您的架构有所启发。
这是另一个...从不同的角度来看。
ikurts, this is definitely not good practice. Your UIs, however many there are, should have absolutely nothing to do with communications. You should:
It sounds like you want to follow best practices in setting up your app. You're gonna get a lot of feedback on this question i think and all of it will sound something like this. Do yourself a favor and follow it. And stay away from comm logic in forms!!!
A few more thoughts:
i'm not sure why you want to break this up into three screens when two seem logical: 1) network settings dialog 2) game play dialog that could accommodate both the battleship UI and your chat UI. This configuration would also simplify your structure since only one screen, the gameplay/chat screen would need to be updated. The settings dialog would be just that.
Here is an example of a threaded chat application on CodeProject which would server well as a code base to get started. i imagine that your battleship moves would simply be "special" chat messages that specify board hits.
Also, here's an example of a network enabled tic tac toe game that may yield clues as to developing a client/sever game.
Don't shy away from what seems difficult! My suggestion is to first write a chat/communication client which has no UI, perhaps just console output. Then add a screen and you'll see that you won't have to marry the window to the network stuff.
Good luck!
More links:
Here's a nice discussion about MVC/MVP that may enlighten your architecture.
And here's another... From a different angle.
您应该将通信分成不同的类（而不是在表单中）。
但是，为了保持表单彼此“同步”，您可以使用 C# 事件（以及处理它们的委托）来通知一个表单另一表单上发生了某些情况。您已经使用事件来处理所有表单操作（鼠标按钮单击等），因此您应该对它的工作原理有一个基本的了解，网上有很多关于“c# 事件”和“c# 事件处理”的文章“（有一些适合您的搜索词）将为您提供更多信息，因此我不会在这里详细介绍。事件的优点是系统保持松散耦合，任何人都可以订阅它们，因此您将来可以很容易地添加第四种形式并让它“监听”它需要的信息。
You should separate the comms into a different class (not in a Form).
However, to keep your forms "in sync" with each other, you can use c# events (and delegates to handle them) to inform one form that something has happened on another form. You're using events to handle all the form actions (mouse button clicks etc) already, so you should have a basic idea of how it works, and there are lots of articles on the net about "c# events" and "c# event handling" (there are some search terms for you) that will give you more info, so I won't go into detail here. The advantage of events is that the system remains loosely coupled, and anybody can subscribe to them, so it's really easy for you to add a fourth form in the future and get it to "listen" to the information it needs.