Microsoft .Net Remoting系列教程之三-Remoting事件处理全

揭开.NET Remoting中事件处理的神秘面纱

在.NET Remoting中处理事件，是一种将分布式应用程序各个部分紧密连接起来的强大机制。尽管这个技术拥有众多优点，但其中的一些复杂性和细节可能会让开发者望而却步。本文将带你深入了解Remoting中的事件处理，揭示其中的技巧与奥秘。

在Remoting中，分布式程序通常包含三个关键部分：远程对象、服务端和客户端。从事件的角度来看，主要有三种形式：服务端订阅客户端事件、客户端订阅服务端事件以及客户端之间的订阅事件。

我们来服务端订阅客户端事件的情形。想象一下，这就像一个下级向上级发送传真的场景。客户端发送消息，服务端捕捉这个消息并响应。在技术上，我们通过定义远程对象中的委托来实现这一机制。远程对象就像是一辆运送信件的汽车，而事件消息则是汽车所装载的信件。

为了模拟这个流程，我们首先需要定义一个公共接口程序集（Common.dll），在其中定义一个名为FaxEventHandler的公共委托。然后，在另一个程序集（FaxBusiness.dll）中，我们定义了一个处理具体传真业务的远程对象类。在这个类中，我们添加了对公共接口程序集的引用，并定义了一个静态事件FaxSendedEvent，其类型就是我们之前在公共程序集中定义的委托类型。

通过深入理解和掌握Remoting中的事件处理机制，我们可以更灵活地构建分布式应用程序。无论你是在处理服务端订阅客户端事件、客户端订阅服务端事件还是客户端之间的订阅事件，关键在于理解并正确应用远程对象和委托的概念。通过本文的讲解，相信你已经对.NET Remoting中的事件处理有了更深入的了解。希望你在实践中能够运用这些知识，构建出更强大、更稳定的应用程序。在远程对象生命周期与事件激活机制的过程中，我们了解到一种显而易见的道理：如果不设定生命周期的限制，一旦远程对象的生命周期结束，相关事件将无法被激活。这一核心原理在分布式应用程序中尤为重要，它确保了系统各组件之间的协同工作。

接下来，我们将分别实现客户端和服务端程序。服务端是一个Windows应用程序，其界面设计简洁直观。在加载窗体时，我们需要注册通道和远程对象。

服务端代码示例：

在窗体加载时，我们创建一个HttpChannel实例并注册到ChannelServices，然后注册一个远程对象。这里采用的是SingleTon模式，确保只有一个远程对象实例存在。值得注意的是，我们添加了一行注册事件的代码。

```csharp

private void ServerForm_Load(object sender, System.EventArgs e)

{

HttpChannel channel = new HttpChannel(8080);

ChannelServices.RegisterChannel(channel);

RemotingConfiguration.RegisterWellKnownServiceType(

typeof(FaxBusiness), "FaxBusiness.soap", WellKnownObjectMode.Singleton);

FaxBusiness.FaxSendedEvent += new FaxEventHandler(OnFaxSended);

}

```

这行代码如同将服务端传真机设置为“自动”模式，一直监听来自客户端的传真信息。一旦接收到信息，就会触发OnFaxSended事件处理方法。

事件处理方法示例：

```csharp

public void OnFaxSended(string fax)

{

txtFax.Text += fax;

txtFax.Text += System.Environment.NewLine;

}

```

此方法简单地将收到的传真内容显示在一个多行文本框中。

而客户端同样是一个Windows应用程序，代码相对简单。在窗体加载时，客户端激活远程对象。

客户端代码示例：

```csharp

private void ClientForm_Load(object sender, System.EventArgs e)

{

HttpChannel channel = new HttpChannel(0);

ChannelServices.RegisterChannel(channel);

faxBus = (IFaxBusiness)Activator.GetObject(typeof(IFaxBusiness), "

}

```

客户端的界面中有一个多行文本框和一个按钮，用于发送传真。在按钮的单击事件中，调用远程对象的SendFax()方法发送传真。

发送传真代码示例：

```csharp

private void btnSend_Click(object sender, System.EventArgs e)

{

if (txtFax.Text != String.Empty)

{

string fax = "来自" + GetIpAddress() + "客户端的传真:" + System.Environment.NewLine;

fax += txtFax.Text;

faxBus.SendFax(fax);

}

else

{

MessageBox.Show("请输入传真内容!");

}

}

```

为了标识发送传真的客户端，我们添加了获取客户端IP地址的逻辑，并在传真内容中显示。为了确保代码的正常运行，需要引用DNS的命名空间。客户端只需添加公共程序集的引用即可。

通过这种方式，我们实现了基于分布式处理程序的远程对象激活和事件处理机制，使客户端和服务端能够协同工作，完成传真的发送和接收功能。在服务的世界里，每一个进程都在进行着各种繁忙的工作。在客户端与服务端的交互过程中，我们需要通过公共程序集和远程对象程序集的引用，来确保信息的顺畅传递。想象一下，我们完成了一项任务，就像发送一份简陋的传真机客户端，将信息编织成一个个字节，发送出去。我们心中暗自欣喜，因为我们的请假条已经成功地传递给了老板。此刻的惬意仿佛一阵甜美的清风。

但是我们的挑战并未结束，接下来我们要的是如何让客户端订阅服务端的消息事件。这就像是我们想要接收来自服务端的通知或消息更新。想象一下，如果我们能像吃甘蔗一样，先吃最甜的部分，那么这个过程就会变得更加愉快。那么如何使客户端订阅服务端的消息事件呢？这是一个值得我们深思的问题。

在远程对象技术中，事件通常被放置在远程对象中。当客户端激活这些对象后，就可以发送消息了。而在服务端，只需要订阅这些事件即可接收消息。我们的目标是要让客户端订阅事件并接收来自服务端的消息。那么该如何实现呢？这就涉及到远程对象的激活方式了。

回顾一下，有三种常见的激活方式：SingleCall激活方式、SingleTon激活方式和客户端激活方式。在服务端，我们需要注册这些远程对象以便客户端能够访问它们。我们不能在服务端显式创建远程对象的实例，因为这样做会导致客户端获得的代理对象与服务端创建的实例不一致，使得客户端无法接收到消息。

那么，我们该如何解决这个问题呢？这就需要使用到Remoting的Marshal方法了。这个方法允许我们显式地创建远程对象的实例，并将其代理对象Marshal到通道中。只要这个对象还在运行，它的代理就会一直存在，这样客户端就能接收到服务端发送的消息了。通过这个方式，我们就可以解决之前的问题，实现客户端订阅服务端的事件了。接下来我们将深入具体的实现方法。在公共程序集的世界里，我们了广播事件的奥秘，定义了`IBroadCast`接口和相应的实现类。当我们谈及远程对象时，服务端与客户端之间的通信成为了关键。事件广播与消息传递在这一过程中发挥着重要的作用。今天，我们将深入狼蚁网站的SEO优化问题，并在服务端实现相关的功能。

在实现之前，让我们再次聚焦服务端与客户端的事件订阅机制。在第一节中，服务端订阅了客户端的事件。事件本身并未传输，仅仅是被序列化的消息——这就是我们的“Fax”。而现在，方向发生了变化——服务端需要发送消息，而客户端则订阅这些事件。这些事件被放置在远程对象中，因此必须被序列化以便传输。在.Net Framework 1.1中，微软对序列化的安全级别有所限制。对于委托和事件的序列化和反序列化，默认是禁止的。我们需要调整TypeFilterLevel的属性值为Full枚举值。

在服务端，我们需要注册通道并改变其方式。让我们创建一个新的`StartServer`方法来实现这一过程：

我们创建了两个提供者——`serverProvider`和`clientProvider`，分别用于服务端和客户端的通信。然后设置`serverProvider`的`TypeFilterLevel`属性为`Full`，以确保序列化的安全性。接着，我们创建一个属性字典并设置端口号为8080。然后创建一个新的HttpChannel并注册它。随后实例化我们的广播对象`BroadCastObj`并将其注册为远程对象。

值得注意的是，我们在设置序列化安全级别的语句中使用了`TypeFilterLevel`属性。要使用此属性，我们必须引入相应的命名空间——`using System.Runtime.Serialization.Formatters`。我们的广播对象被声明为公共静态对象，以便在其他窗口中使用。

在主窗口的加载事件中，我们启动服务端并在ListBox控件中添加一条消息，显示服务器已启动。这个ListBox控件用于显示各种信息，如服务器的启动状态。

我们的程序通过调整序列化的安全级别、注册远程对象和使用事件广播机制，实现了服务端与客户端之间的有效通信。在实现狼蚁网站SEO优化的服务端时，我们确保了代码的可读性和流畅性，使得程序更加易于理解和维护。现在，我们可以进一步测试和优化我们的程序，以提供更好的用户体验。在数字化世界中，信息的传递与共享变得至关重要。而在这背后，有一个神秘的按钮——BroadCast按钮，它如同信息世界的广播站，一旦按下，便会弹出一个对话框，引导我们进入广播的世界。

这个BroadCast按钮背后的代码逻辑简单而巧妙。当我们点击这个按钮时，系统会创建一个新的BroadCastForm窗体，并将其居中显示在父窗体上，然后呈现为一个对话框。这个对话框的核心是一个Send按钮，它的功能就是发送信息。

在信息栏txtInfo中输入信息后，点击Send按钮，信息将被发送到服务器。这个过程仅仅是调用了远程对象的发送消息方法，简单而直接。

接下来，我们转向客户端的实现。客户端的代码结构与服务端相似，但在实现细节上有所不同。在客户端启动时，需要设置一个特殊的通道，这个通道负责与服务端进行通信。在这个过程中，涉及到一个关键的步骤——注册通道并创建远程对象。

当客户端运行时，它会自动订阅服务端的一个事件——BroadCastEvent。这个事件的作用是接收服务端发送的消息。在客户端程序中，有一个名为BroadCastingMessage的方法，它是用来处理接收到的消息的。在实际运行中，当尝试订阅这个事件时，会出现一个错误。

这个错误的根源在于客户端的委托是通过序列化获得的。在订阅事件时，委托需要装载包含与签名相同的方法的程序集，也就是BroadCastingMessage方法所在的Client程序集。这个装载的过程是在服务端进行的，而服务端并没有Client程序集的存在，这就导致了错误的产生。

为了解决这个问题，我们需要确保服务端能够访问到Client程序集。一种可能的解决方案是在服务端也部署Client程序集的副本，或者在序列化委托时，采取一些额外的安全措施来确保程序集的完整性。这样，当服务端尝试装载委托时，就能够找到必要的方法，错误也就不会再发生了。

BroadCast按钮及其背后的代码逻辑构成了信息传递的关键环节。通过优化和调整，我们可以让这个环节运行得更加顺畅，实现信息的快速、准确传递。在这个过程中，我们不仅要关注代码的逻辑，还要关注程序集的管理和序列化过程中的细节。只有这样，我们才能确保信息的顺利传递，让数字化世界更加畅通无阻。在客户端与服务器交互的复杂环境中，事件广播机制常常需要巧妙的设计以确保信息流畅传递。文章中的BroadCastingMessage方法确实需要在客户端实现，而服务端的事件则由远程对象捕获。这就好像我们需要在客户端和服务器之间找到一个平衡点，既要满足客户端的需求，又要顾及到服务端的处理逻辑。这种情况中，如何调和这种看似矛盾的需求呢？我们可以借鉴一个简单的例子来理解。

想象一下我们有两个变量x和y，我们想交换它们的值。怎么办？引入一个中间变量z就可以轻松实现。这个过程其实就是一个中间人的角色，帮助我们完成两个变量值的交换。同样地，在我们的场景中，也需要这样一个“中间人”——EventWrapper类。这个类充当了客户端和服务端之间的桥梁，帮助我们解决委托装载程序集的问题。

EventWrapper类是一个特殊的包装类，它包含了本地事件BroadCastEventHandler LocalBroadCastEvent，并且有一个BroadCasting方法用于触发这个事件。这个类最重要的特点是它继承了MarshalByRefObject，这意味着它可以跨应用程序域进行通信。由于它需要在客户端和服务端都部署，因此被放置在公共程序集Common.dll中。

在客户端代码中，我们首先通过Activator.GetObject方法获取远程对象watch，然后创建EventWrapper的实例wrapper。我们将本地的BroadCastingMessage方法绑定到wrapper的LocalBroadCastEvent事件上。这样，当LocalBroadCastEvent事件被触发时，就会调用BroadCastingMessage方法。虽然事件看起来还在客户端，但实际上我们已经通过EventWrapper这个中间人完成了从客户端到服务端的过渡。

接下来，我们通过远程对象watch订阅EventWrapper的BroadCasting事件。由于BroadCasting所在的程序集是公共程序集，已经在服务端和客户端都部署了，所以不会出现找不到程序集的问题。这样，当服务端触发远程对象中的事件时，就会通过BroadCasting方法传递到客户端的EventWrapper中，最终触发LocalBroadCastEvent事件，进而调用BroadCastingMessage方法。

通过引入EventWrapper这个中间对象，我们成功解决了委托装载程序集的问题。它就像是一个桥梁，连接了客户端和服务端，使得事件可以在两者之间顺畅传递。由于EventWrapper继承了MarshalByRefObject，我们可以确保跨应用程序域的通信能够顺利进行。这种设计体现了编程中的智慧，让我们能够在复杂的环境中巧妙地解决问题。远程通信：服务端、客户端与事件的交互

想象一下运行服务端，随后启动客户端，界面呈现眼前。点击“BroadCast”按钮，一条广播消息瞬间传送。此刻，再打开多个客户端，它们无一例外地接收到了这条信息。这就是广播的魅力，无论多少客户端，都能实时接收消息。如果你觉得这广播声音太吵，你完全可以在客户端选择取消订阅。那么这一切是如何实现的呢？让我们深入了解。

一、服务端广播的实现

当我们在服务端点击“BroadCast”按钮时，触发了一个事件，这个事件会向所有订阅者发送广播消息。在事件处理过程中，我们使用了EventWrapper对象来管理这些事件。当我们关闭某个客户端时，如果没有取消订阅，可能会导致其他客户端无法正常接收消息。为了解决这个问题，我们可以考虑以下改进方案。

二、客户端订阅与取消订阅

客户端订阅事件相对简单。发送信息的客户端只需获取远程对象后发送消息即可，而接收信息的客户端则负责订阅该事件。订阅的方法和之前的情况类似。当客户端需要取消订阅时，我们可以通过取消事件订阅来实现。例如，在btnCancle_Click事件中，我们通过移除事件订阅者来取消订阅。wrapper对象应该已经被声明为私有对象。取消订阅后，即使服务端再次广播消息，当前客户端也不会收到任何信息。

三、自定义事件参数

在事件处理中，我们默认使用了EventArgs作为事件参数。如果需要定义自己的事件参数，就需要做一些额外的操作。自定义的事件参数必须标记为可序列化，并放置在公共程序集中，同时部署到服务端和客户端。例如，[Serializable]属性就必须应用在自定义的BroadcastEventArgs类中。这样，我们就可以在触发事件时传递自定义的参数信息。

四、持续改进与问题处理

在远程对象类和EventWrapper类中，触发事件方法的Attribute[OneWay]在实际应用中可能经常被忽略或被注释掉。这个属性是为了处理当事件的订阅者发生故障或异常时的异常情况。例如，当发送事件消息时，如果找不到正确的事件订阅者或事件订阅者出现故障，发送事件一方会因为找不到目标而引发异常。为了解决这个问题，我们可以考虑使用OneWay属性来确保即使订阅者出现问题也不会影响到事件的发送和其他客户端的正常接收。我们还需要对程序进行进一步的优化和改进，确保在各种情况下都能稳定地发送和接收事件消息。

远程通信中的服务端与客户端交互以及事件处理是一个复杂而有趣的过程。通过理解并实现这些基本功能，我们可以进一步扩展和改进程序，以满足更复杂的需求。在这个过程中，不断地学习和新技术将使我们不断进步。在客户端即将关闭的时刻，事件的订阅并未被取消，因此我们需要对客户端的关闭过程进行细致处理。

当客户端窗体即将关闭时，会触发 `ClientForm_Closing` 事件。在这个事件中，我们需要取消事件的订阅，确保不会发生未处理的事件。这只是处理正常关闭的情况。如果客户端因为意外原因，如突然断电而关闭，我们还需要采取额外的措施。

对于这种情况，我们可以借助 `OneWayAttribute`。当事件无法送达时，如果使用了 `OneWayAttribute`，系统会自动忽略这个事件的返回信息，使得发送方会认为消息已经成功发送。这在客户端异常关闭的情况下非常有用，因为即使客户端无法处理事件，服务端也能继续发送广播信息。

仅仅使用 `OneWayAttribute` 并不够友好。发送广播消息的一方无法得知哪些客户端发生了错误。为了解决这个问题，我们可以在发送信息时检查委托链，并在遍历中捕获异常。当某个委托发生异常时，我们可以显示提示信息，然后继续遍历，确保其他订阅者可以正常接收消息。

对远程对象的改进如下：

在广播信息的方法中，我们遍历所有的事件订阅者，并尝试调用他们的处理方法。如果某个订阅者发生异常，我们会显示一个提示框，告知用户哪个事件订阅者发生了错误，并取消该订阅者的订阅。这样既能保证异常信息的提示，又能保证其他订阅者正常接收消息。

现在我们来测试一下这个改进的效果。打开服务端，然后启动三个客户端。发送广播消息，一切正常。然后关闭其中一个客户端窗口，再发送广播消息。服务端会报告某个事件订阅者发生错误，并取消其订阅。但其他两个客户端仍然可以正常接收广播信息。

.NET Remoting中的事件处理指南

亲爱的开发者们，你们好！在这篇指南中，我们将深入.NET Remoting中的事件处理机制。如果你正在寻找关于Remoting事件处理的清晰解释和实践示例，那么这篇文章将为你提供详尽的解答。

一、客户端发送传真（Remoting事件）

我们有一个压缩包，里面包含了关于客户端发送Remoting事件的代码。这是整个事件处理流程的基础部分，它为后续服务端处理提供了触发机制。

二、服务端广播与客户端订阅服务端事件

接下来，我们转向第二个压缩包，其中包含了服务端广播和客户端订阅服务端事件的代码。这部分代码被包含在特定的区域标记（region 客户端订阅服务端事件 endregion）内，方便我们进行管理和理解。如果你想运行这部分程序，请确保第三节代码被注释掉。反之亦然。当你运行示例程序时，首先要启动服务端程序，然后再启动客户端程序，否则可能会遇到“基础连接已关闭”的错误。

三、客户端订阅客户端事件

在第三节代码中（包含在region 客户端订阅客户端事件 endregion中），我们将会看到客户端如何订阅自己的事件。如果你想专注于服务端广播的功能，这部分代码同样可以被注释掉。

四、解决方案与改进

所有的解决方案都被放置在Common（或ICommon）文件夹中，方便查找和使用。近期我们对服务端广播的代码进行了改进，并放置在“Remoting事件(服务端广播改进)压缩包中。新的代码有哪些不同？又有什么优势？欢迎大家对比并分享你的看法。

以上就是.NET Remoting中事件处理机制的全部内容。我们希望这篇文章能为你提供一个参考，同时也希望大家能多多支持我们的博客——狼蚁SEO。如果你对这篇文章有任何疑问或建议，欢迎留言交流。让我们一起学习进步，为软件开发添砖加瓦！

请注意，为了运行这些示例代码，你需要了解.NET Remoting的基础知识，并且按照文章中的指示进行操作。希望这篇文章能对你有所帮助！如果你有任何问题或需要进一步的澄清，请随时联系我们。让我们一起编程的奥秘！

（注：以上内容仅为技术分享和学习交流之用，如有涉及版权问题请及时告知。）

Cambrian的系统渲染已完毕（cambrian.render('body')）。