我不能忍受像线程和计时器这样的拖放控件。这些控制感觉与它们存在的实际本质相去甚远。拖放线程？我希望拖放器在他们这样做之前了解幕后发生的事情。
这些抽象是不是离金属太远了？他们是在帮助还是伤害程序员？
问问题
963 次
9 回答
6
我不认为他们是邪恶的。在窗体上删除控件只是“new Thread()”或“new Timer()”的另一种说法，许多程序员也并不真正理解。
简单的解决方案并不总能满足您的需求，但当它们满足时，使用它们有什么问题？
然而，如果使用拖放的东西是程序员知道如何做事的唯一方法，那不是一个很好的程序员。
于 2009-01-21T16:32:57.850 回答
4
我认为他们正在伤害程序员。拖放不是编程。
我可能会用大笔画笔，但令我震惊的是，我遇到的大多数 Web 应用程序开发人员（特别是 .NET WebForm 开发人员）在涉及 HTTP 模型、POST 和 POST 等基本知识时完全缺乏知识。由于他们遇到了抽象，GET 超出了他们的掌握。
这篇文章读起来很有趣，完全反映了我的观点。
于 2009-01-21T16:29:11.307 回答
3
就个人而言，我没有理由在我的职业生涯中使用多线程编程，尽管我确实在大学学习过。所以 Timer 控件对我有很大帮助，特别是因为我不想学习如何在 .NET 中进行多线程编程，只是为了获得一个简单的功能。
于 2009-01-21T16:26:52.467 回答
2
“拖放”意味着使用 IDE 的所见即所得部分？
我是在 VB6 和 Dreamweaver 代码中长大的，所以如果是这样的话，我会选择“非常肯定”。
于 2009-01-21T16:30:10.040 回答
2
BackgroundWorker 增加了真正的价值。它生成的代码（通过使用事件模型）比通过使用委托调用手动执行线程，然后使用 Control.Invoke 将结果编组回 UI 线程来生成更简洁的代码。
我在没有测试 Control.IsHandleCreated 的情况下测试 Control.InvokeRequired 已经被烧死了。当代码已经在 UI 线程上执行并且控件不存在时，Control.InvokeRequired 将返回 false。如果我使用 BackgroudWorker，我可能不会遇到这个问题。
于 2009-01-21T16:52:06.627 回答
1
（从问题上的 .Net 标记来看，我假设我们在谈论拖放控件时谈论的是 Visual Studio 设计者。）
我不认为它们是邪恶的，尽管我同意它并不总是最适合组件（如 Thread）的隐喻。
对我来说，控件的拖放并不是“这是一个远离金属的 UI 组件”的声明。相反，这是我“希望设计师为我管理此组件的生命周期”的声明。从这个角度来看，通过拖放添加诸如后台工作者之类的东西是非常明智的。事实上，这是我最喜欢的将任何 IDisposable 对象包含为（例如）UserControl 或 Form 的成员的方法。这样，代码生成器就为我处理好了，我可以更多地关注我的代码所做的事情，而不是布线。
于 2009-01-21T17:19:55.183 回答
0
我认为对于基本的长期运行；或一种情况，后台工作人员控制非常适合这些情况。如果您正在做比这更高级的事情，那么您应该研究线程和多线程设计的高级用途。
因此，对于一种快速启动和运行线程的方法，它并没有什么坏处。但是将其用作执行线程的唯一方法，那么它肯定会伤害程序员。
于 2009-01-21T16:30:50.100 回答
0
它是一个 UI 隐喻。
您拖放的东西应该是文件、文档或其他“东西”到容器、垃圾箱、碎纸机、打印机或其他“东西”的“东西”。
将线程/任务拖放到计时器会失去基本的比喻并且感觉不对。
右键单击和下拉对于像“开始计时器”这样的“动词”来说要好得多。
于 2009-01-21T16:34:04.463 回答
0
好消息是，由于 .NET，拖放控件不需要使用拖放样式。我个人认为，虽然拖放对于原型制作来说是可以的，但您的要求越复杂，您就越有可能发现设计师的限制和阻碍。一个简单的例子是当您调整包含窗口大小时应该扩展的表单。您很快就会发现自己编写了如此多的代码，以致于完全放弃设计器会更好。
那是在我们讨论设计器中的错误之前，例如，删除所有事件......
于 2009-01-21T17:06:00.093 回答