编写可由 3rd 方应用程序使用的自定义事件

Question

是否可以编写可由 3rd 方应用程序处理的自定义事件？

我们有一个现有的应用程序，我们发现许多使用该应用程序的人正在使用 sql 触发器来自定义编写他们自己确定的功能，当我们的应用程序发生事情时。

这导致某些情况下，我们自己的流程会因为劣质的第 3 方触发器阻止我们的应用而变慢。

我在想，如果我们可以引发他们可以在自己的服务或应用程序中处理的事件，而不是必须使用触发器，那么我们可以让第三方开发人员更容易做到这一点。

这样我们就会失去阻塞，因为我们可以触发事件并继续。此外，它们的缓慢/潜在崩溃也会发生在我们的流程之外。

A) 这是一种合理的方法吗？

B) 这可能吗？我可以将事件的范围超出我的应用范围吗？

编辑

从那以后我发现了其他有趣的相关问题：

1. wcf cross application communication
2. Interprocess pubsub without network dependency
3. Listen for events in another application（这似乎非常接近我所追求的）

我想我正在寻找最简单的方法，但如果我们想在公司内的许多其他应用程序中采用这种方法，我们将面临一些进一步的挑战：

我们在 vb6 和 delphi 中有一些较旧的应用程序 - 我只是希望能够在我的（或第 3 方）较新的 C# 应用程序或服务中监听它们的事件。

现在，我将看看： Managed Spy 和 http://pubsub.codeplex.com

Answer 1

不，事件只能由加载到您自己的进程中的代码使用。如果你现在不信任这些人，你真的不想让自己暴露在你自己的进程中加载​​的伪劣代码，并抛出未处理的异常来终止你的应用程序。你会接到电话，而不是他们。此外，他们会使用这样的事件来运行降低应用程序速度的代码。

一般来说，您使用 dbase 执行的任何操作都会产生完全无法预测的开销。不仅仅是因为其他人添加的触发器，dbase 服务器可能会简单地被其他工作拖累，并且随着时间的推移自然会变慢，因为它存储了越来越多的数据。确保这不会使您的应用程序难以使用或使用起来不愉快，dbase 操作通常必须在工作线程上运行或使用 BeginExecuteXxxx() 等异步完成。并在您的 UI 中清楚地表明进度是由 dbase 服务器停止的，而不是您编写的任何代码。让您不必进行大量解释。

Answer 2

您要做的基本上是将消息发送到其他进程。为此，您需要某种IPC 机制。因为听起来每条消息都会有多个听众，所以mailslot 可能是最好的方法。不幸的是，.NET 没有对邮槽的内置支持，因此您必须使用P/Invoke。

如果您正在寻找内置解决方案，则可以使用命名管道、WCF、.NET Remoting 或裸 TCP 或 UDP。但是，对于其中任何一个，您都必须遍历所有侦听器，并一次将消息发送给每个侦听器，这没什么大不了的，但是保持单独的连接更多的是很麻烦。

请注意，使用 WCF 和 .NET Remoting，您几乎也限制了您的客户端使用 .NET。如果您的客户端可能是本机或其他平台，那么邮槽、命名管道和 TCP/IP 是您的最佳选择。