mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-06 17:36:53 +01:00
The 35 articles still in their seed form previously carried a banner reading "Seed article. ... Domain stewards should expand, restructure, and refine as needed." For a community preview, that phrasing reads as "TODO left in production" to first-time visitors. Replace all three banner variants (performance-seeded, security-seeded, community-ported) with a single positive invitation: > Contributions welcome — open a PR to refine or extend this article. Content and structure of the articles are unchanged; only the leading quote block differs. Articles that had their banner fully stripped in the earlier triage pass (the showcase-grade ten) are unaffected.
27 lines
1.1 KiB
Markdown
27 lines
1.1 KiB
Markdown
---
|
|
bc-version: [all]
|
|
domain: performance
|
|
keywords: [event, subscriber, publisher, extension]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [all]
|
|
---
|
|
|
|
# Keep event subscribers lightweight
|
|
|
|
> Contributions welcome — open a PR to refine or extend this article.
|
|
|
|
## Description
|
|
|
|
Event subscribers run synchronously on the publisher's thread. If a subscriber does heavy work — a database query, a web service call, a layout render — every caller of the publisher pays that cost. Subscribers on hot events (OnAfterValidate on common fields, OnBeforeInsert on ledger-entry-like tables) can multiply a small per-call cost into a system-wide regression.
|
|
|
|
## Best Practice
|
|
|
|
Keep subscribers small: guard early with inexpensive checks, defer heavy work to a task queue or a background session, and cache results across invocations when the data is stable.
|
|
|
|
## Anti Pattern
|
|
|
|
Calling an external web service, running a report, or iterating a large table from inside an event subscriber on a hot publisher makes every operation on that publisher as slow as the heaviest subscriber.
|
|
|
|
See sample: `keep-event-subscribers-lightweight.bad.al`.
|
|
|