Windows窗体中事件处理程序的常见设计模式是什么

发布于 2024-10-11 08:19:05 字数 164 浏览 2 评论 0原文

我想知道在 WinForm 中定义事件处理程序的正确方法是什么。我问这个问题是因为我有一个应用程序,其中只有一些事件处理程序具有内部逻辑,其他事件处理程序仅调用其他地方定义的方法。这样可以吗?我有点担心,因为也许是一个糟糕的设计,在特定的时刻它会给我带来麻烦。拥有内部具有密集逻辑的事件处理程序是一个不好的模式吗?

i would like to know what is the correct way to define an Event Handler in WinForm. I'm asking this because i have one application in where only some event handlers has logic inside, others only make calls to methods defined elsewhere. Is this fine?, i'm a little worried because maybe is a bad design that in a given moment its going to give me troubles. Having event handlers with intensive logic inside is a bad pattern?

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

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

发布评论

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

评论(3

吖咩 2024-10-18 08:19:05

一般来说,您在 Winforms 事件处理程序中执行的操作没有任何限制。但它有自己很容易看到的副作用,如果你做了很多工作,那么用户界面就会变得紧张。它不再响应鼠标点击,也不再重新绘制自身。大约 3 秒后,Windows 将窗体替换为标题栏中带有“无响应”的幽灵窗口。

您必须编写大量代码才能触发该条件,一秒钟超过 4十亿 机器指令。典型的 UI 冻结是由于等待其他任务完成工作(例如数据库查询)而导致的。

这很丑而且不会给人留下深刻的印象。并且可能会让您使用用户界面时感到不舒服。用户敲击没有响应的按钮并不是什么好事。您可以使用工作线程来解决这个问题,BackGroundWorker 就是为此而设计的。这并不容易做到,只有当你有真正的问题需要解决时才使用它。不要假设任何事情。

There are in general no restrictions on what you do in a Winforms event handler. But it has side-effects that are easy to see for yourself, if you do a lot of work then the user interface goes catatonic. It no longer responds to mouse clicks, it doesn't repaint itself anymore. After about 3 seconds, Windows replaces the form with the ghost window with "Not Responding" in the title bar.

You'd have to write a great deal of code to trigger that condition, one second is over 4 billion machine instructions. The typical UI freeze is caused by waiting for something else to get the job done, a dbase query for example.

That is ugly and doesn't make a great impression. And can make it uncomfortable to use your user interface. Nothing very pretty about a user banging away on a button that doesn't respond. You'd use a work threader to solve this problem, BackGroundWorker is made for that. This is not so easy to get right, only use this if you have a real problem to solve. Don't assume anything.

任谁 2024-10-18 08:19:05

事件处理程序的复杂逻辑在某些情况下是不好的,但并非总是如此。通常不好的事情是在处理程序中做大量工作来重新绘制数据网格或类似的单元格,这会导致 gui 闪烁。您可以使此类处理程序异步。
只要防御跨线程操作异常,从事件处理程序调用其他方法是可以的。
但是,您必须考虑您的架构需求并从那里开始。

Complicated logic of an event handler is bad in some cases but not always. Typically bad thing would be to do a lot of work in a handler to cell repaint of a datagrid or similar that would cause gui to flicker. You can make such handlers asynchronous.
Calling other methods from event handlers is ok as long as you defend agains crossthreadedoperationexceptions.
However, you must consider your architecture needs and jump from there.

凉城已无爱 2024-10-18 08:19:05

<块引用>

在事件处理程序中包含密集逻辑是一种不好的模式吗?

如果您自己问这个问题:是的。可能会有一些例外,但 UI 事件处理程序中的代码过多通常是糟糕设计的标志。

您应该看看 MVP(MVP-被动视图和 MVP-监督控制器),甚至可能是 MVVM 和 MVC。这些是将逻辑与表示分离的最“著名”的设计模式。
就我个人而言,我更喜欢 WinForms 中的 MVP-Passive View,但对此有很多意见。

Having event handlers with intensive logic inside is a bad pattern?

If you are asking this question yourself: Yes. There might be some exceptions, but too much code inside UI-eventhandlers is often a mark of bad design.

You should take a look at MVP (both MVP-Passive View and MVP-Supervising controller) and maybe even MVVM and MVC. Those are the most "famous" design patterns to seperate the logic from the presentation.
Personally, I prefer MVP-Passive View in WinForms but there are many opinions on that.

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