Action 委托与与处置有关的事件处理程序

| 我正在寻找体系结构建议,以及对委托人和lambda的更深刻理解(除了需要解决一个实际问题之外!) 我们有代码通过pda上的串行端口与设备(秤)交互。我们连接一个视图以从设备接收数据。由于一次只能有一个视图“连接”到我们的比例尺实例,因此我们使用了Action类型的属性来处理比例尺实例和视图之间的交互(而不是订阅事件)。然后,视图将该属性设置为一个lambda,该lambda从比例尺中获取值并修改UI。 我们目前遇到的问题是关于“处置我们的观点”。如果在用户关闭视图(此时我们使用CF时强制执行Dispose)时,缩放比例当前正在发送数据(并且我们位于Action处理程序内部),则该应用会挂起:Action Lambda永远不会结束运行,并且尝试关闭SerialPort时,Scale实例的Dispose挂起。 与事件相比,在这种情况下如何处理Action是类的属性上是否存在关键区别? 根据日志详细信息,当在视图上调用Dispose时,代码位于Action lambda(用于修改某些UI元素)中。它们都在UI线程上-如何同时运行?昨晚我睡不着觉吗? 有人在这里看到一些较差的体系结构决策,应该纠正吗? 谢谢。如果描述不够合理,我可以尝试在此处获取一些代码示例。     
已邀请:
当不用作表达式树时,lambda将转换为普通委托,因此这不应该成为问题。 但是整个过程听起来像是一个死锁/并发问题。与其直接关闭串行端口,不如在操作处理程序的持续时间内使用一个信号(该信号可能同时在另一个线程中运行-再次检查),以便您可以在关闭端口之前优雅地等待它终止。     
不-事件实际上只是一个委托,就像Action一样 它们不能在同一线程中同时运行-您更有可能在单独的线程中进行处置,或者操作处理程序在单独的线程中运行。如果这是对串行端口的响应,请意识到串行端口事件在后台线程上发生。 从架构的角度来看,这里确实没有足够的信息来说明应该或不应该更改的内容。话虽这么说,但我质疑您为什么不使用事件-与使用事件处理程序相比,使用“动作”确实没有优势,但是后者听起来更适合心理模型,并且会显示出您的意图更加清晰。     

要回复问题请先登录注册