【发布时间】：2009-12-22 17:22:08
【问题描述】：
我正在实现一个用户控件，该控件具有一个将 Action 委托作为参数的方法。
尝试将委托存储在控制状态中会产生序列化错误。甚至可以将委托序列化为控制状态吗？
BP
【问题讨论】：
标签： asp.net serialization delegates
【发布时间】：2009-12-22 17:22:08
【问题描述】：
不容易 - 它可能会为潜在问题打开大门。
理论上可以使用反射来确定委托调用的对象的哪个方法，并为其编写自定义序列化过程。反序列化后，您将再次需要编写逻辑将信息转换为委托引用。
问题在于，在一般情况下，并非总是可以在运行时发现需要为其重新生成委托的对象。如果委托引用了 lambda 或匿名方法，这会使事情变得更加复杂，因为它们可能涉及闭包。
你可能会更好：
不保留请求之间的操作委托，并让 ASP.NET 代码在回发时重新附加委托。恕我直言，这是风险最小的选择。
-
将委托引用存储在会话状态中，并在回发时将其重新附加到反序列化对象。此选项存在风险，原因有两个：
a) 如果最终用户从不回发，或者您忘记从服务器状态清除对象，则无限期地在内存中保留对象引用。
b) 如果委托引用页面元素（控件等），您可以运行 因为委托将针对上一个请求中的对象进行操作，而不是新请求。
【讨论】：
-
和我猜想的差不多……不过，我愿意试一试。解决方案 1 需要存储一些证据来确定要重新附加的方法/委托。在解决方案 1 中，会话将在 60 分钟后超时，届时代理将从服务器状态中删除，不是吗？谢谢，BP
-
会话超时将导致状态被丢弃，并且委托和委托保存在内存中的任何对象图都会被丢弃。但是，如果您正在构建一个有许多用户访问的站点，如果该委托导致在请求之间保留一个大型对象图，这可能会占用服务器资源。 Alo，如果您不清除每个响应的会话状态，则最终可能会在内存中出现多个实例（假设您没有重用会话状态键）。如果您重复使用会话状态密钥，您将面临同一用户打开第二个窗口/选项卡并遇到状态冲突的风险
-
根据您在此处的评论，我认为我可以将代表保存到会话状态。 （效果很好！）用户数量少，对象图很小，用户控件被包装在 ajax modaldialog 中，因此不可能进行多次调用。是的！再次感谢。 BP
在这篇文章中，作者序列化了一个 Action 对象，以便稍后执行。 您可以在自己的操作中将序列化扩展为字符串而不是文件。
非常有趣：
http://mikehadlow.blogspot.com/2011/04/serializing-continuations.html
【讨论】：
-
嗯 - 不适用于参数 - 在 cmets 中搜索：“这就是我的意思。将 BuryIt 更改为” 但是谢谢，看起来很酷