-
Notifications
You must be signed in to change notification settings - Fork 77
Packet Handler Decorators #37
Description
What do you think about adding built-in support for Packet Handler Decorators?
We could use an Attribute-based means of assigning Decorators to Packet Handlers and wire them up at startup.
This blog talks about the Command Handler Pattern and has a section about enhancing the pattern with Decorators:
https://blogs.cuttingedge.it/steven/posts/2011/meanwhile-on-the-command-side-of-my-architecture/
The article provides these use case examples:
- Checking the authorization of the current user before commands get executed
- Validating commands before commands get executed
- Measuring the duration of executing commands
- Logging and audit trailing
- Executing commands in the background
- Queuing commands to be processed in a different process
Here's an example of how you might define custom Decorators for a Handler:
[Decorate(
typeof(LoggingHandlerDecorator),
typeof(AuthorizationHandlerDecorator),
typeof(BackgroundJobHandlerDecorator)]
public class SomePacketHandler : PacketHandlerBase<SomePacket>
{
....
}
Having a way to define global or module Decorators could prevent having to add the Decorate attribute to so many Handler classes.
Here's an example of the sort of benefits that Decorators can provide, especially when used with helper Attributes:
[Authorization(30)] // User must have authorization level of 30 for this to succeed
public override Task Process(SomePacket packet, IPacketContext context)
{
...
}
For this example, the AuthorizationHandlerDecorator.Process method might look something like this:
public override async Task Process(SomePacket packet, IPacketContext context)
{
int userAccessLevel = 0; // Get user access level from service
// Gets from the method's Authorization Attribute
int requiredAccessLevel = GetRequiredAccessLevel(packet);
if (userAccessLevel >= requiredAccessLevel)
{
await DecoratedHandler.Process(packet, context);
}
}
Thoughts?