将 Web 应用程序订阅 NServiceBus 中的事件

发布于 2024-12-01 04:47:15 字数 241 浏览 2 评论 0原文

我想知道我的 Web 应用程序如何从服务器订阅事件？我知道网络应用程序不得发布事件。在异步示例中，Web 应用程序将消息发送到服务器。我希望应用程序订阅服务器。换句话说，就是如何处理来自网络应用程序的事件。我不知道如何编写 Global.asax 页面：公共类 Global ：System.Web.HttpApplication 和 void Application_Start(object sender, EventArgs e) 方法。提前致谢，卢伊克

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

倥絔 2024-12-08 04:47:15

我不得不不同意休的观点。 Web 应用程序订阅其他服务发布的事件有非常充分的理由。

通常，这不是您想要对其采取数据库操作的事情。一个主要的示例用例是缓存管理。使用注释中的 UserCreated 示例，Web 应用程序可以通过从缓存中删除其 User 对象来响应 UserCreated。这有助于作为网络场一部分工作的多个 Web 应用程序保持彼此同步。

订阅事件的 Web 应用程序（再次以 UserCreated 为例）的更大胆的用途是创建一个超可扩展的登录服务，该服务永远不需要查询数据库来验证用户身份。启动时，Web 应用程序会将所有用户名和密码哈希加载到内存中的字典中，然后通过添加到该字典来订阅 UserCreated 事件。它还可能订阅 UserPasswordChanged 事件，以便更新该字典。

（在这种情况下，重要的是不要考虑缓存整个用户对象 - 该服务只关心身份验证，而不关心授权，因此只会存储用户名和密码哈希值。）

为了实现这一点，您必须按照在您自己的进程中托管 NServiceBus 中所述，在 Global.asax 中自行设置总线。 .LoadMessageHandlers() 行对于让 NServiceBus 扫描您网站的程序集以查找消息处理程序至关重要。

这是 Web 应用程序的典型流畅配置块：

public static IBus Bus { get; set; }

// In Application_Start()
Bus = NServiceBus.Configure.WithWeb()
        .Log4Net()
        .DefaultBuilder()
        .XmlSerializer()
        .MsmqTransport()
            .IsTransactional(false)
            .PurgeOnStartup(true)
        .UnicastBus()
            .ImpersonateSender(false)
            .LoadMessageHandlers() // <-- only if handling commands/events
        .CreateBus()
        .Start();

由于 Web 应用程序本质上不稳定（它们经常回收并丢失状态），因此通常在 之后使用 .PurgeOnStartup(true) 行.MsmqTransport() 以便在启动期间刷新队列中等待 Web 应用程序的所有消息。这是因为，通常发送给 Web 应用程序的消息是修改状态的指令，但刚刚启动的 Web 应用程序没有状态！当我们知道我们的缓存是空的时，为什么要处理一堆命令来“删除缓存项 X”？

总而言之，您可以（在某些情况下应该）让您的 Web 应用程序订阅来自其他服务的事件，具体取决于您的业务逻辑，您只需小心操作方式即可。

I'm going to have to disagree with Hugh. There are very valid reasons for a web application to subscribe to an event published by another service.

Usually, it's not the kind of thing you want to take database action on. A prime example use case would be for cache management. Using your UserCreated example from the comments, the web application could respond to UserCreated by dropping its User object from the cache. This helps multiple web applications working as part of a web farm to stay in sync with each other.

A more adventuresome use of a web application subscribing to an event (again UserCreated as an example) would be to create an ultra-scalable login service that never has to query the database to authenticate the user. On startup, the web application would load all usernames and password hashes into a dictionary in memory, and then subscribe to a UserCreated event by adding to that dictionary. It would likely also subscribe to a UserPasswordChanged event, in order to update that dictionary.

(It is important in that scenario not to think about caching an entire user object - this service would only be concerned with authentication, not authorization, and so only usernames and password hashes would be stored.)

In order to accomplish this, you have to set up the Bus yourself in the Global.asax as described in Hosting NServiceBus in your own Process. The .LoadMessageHandlers() line is critical to having NServiceBus scan your website's assemblies for message handlers.

This is a typical fluent configuration block for a web application:

public static IBus Bus { get; set; }

// In Application_Start()
Bus = NServiceBus.Configure.WithWeb()
        .Log4Net()
        .DefaultBuilder()
        .XmlSerializer()
        .MsmqTransport()
            .IsTransactional(false)
            .PurgeOnStartup(true)
        .UnicastBus()
            .ImpersonateSender(false)
            .LoadMessageHandlers() // <-- only if handling commands/events
        .CreateBus()
        .Start();

Because web applications are inherently unstable (they recycle and lose their state quite often) it's common to use the .PurgeOnStartup(true) line after .MsmqTransport() in order to flush any messages waiting for the web application in queue during startup. This is because commonly, messages addressed to a web application are instructions to modify state, but a web application just starting up has no state! Why process a bunch of commands to "drop cache item X" when we know for a fact our cache is empty?

So to summarize, you can (and in some cases, should) have your web application subscribe to events from other services, dependent upon your business logic, you just have to be careful about how you do it.

回复收藏 0 原文