You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/guide/handler-conventions.md
+46Lines changed: 46 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -173,6 +173,52 @@ public class UserHandler
173
173
174
174
**Note:** Handlers are singleton by default. Constructor dependencies are resolved once and shared across all invocations.
175
175
176
+
### Open Generic Handlers
177
+
178
+
Handlers can be declared as open generic classes and will be automatically closed for the concrete message type at runtime. This lets you build reusable handler logic that applies to many message types.
- The handler class, not the method, must be generic (generic handler methods are not currently supported).
212
+
- The message type must use the handler's generic parameters (e.g., `UpdateEntity<T>` in `EntityHandler<T>`).
213
+
- Open generic handlers participate in normal invocation rules: exactly one match required for `Invoke / InvokeAsync`; multiple open generics for the same message generic definition will cause an error when invoking (publish supports multiple).
214
+
215
+
Performance Notes:
216
+
217
+
- First invocation of a new closed generic combination incurs a small reflection cost; subsequent calls are cached.
218
+
- Static middleware resolution still applies and middleware can itself be generic.
219
+
220
+
If you need a custom behavior per entity type later, you can still add a concrete handler; the more specific (closed) handler will coexist.
0 commit comments