RequestAttribute adding context

I have a quick architectural question.

In my pursuit to do caching in our services, Ideally, my first thought was that I want to add some new attributes to request DTO’s that govern how service methods should behave (i.e. whether they run caching code or not, what the cache options they should have if they do (i.e TTL, PerUser, PerRequest etc.), and what response headers to return if they do).

So it would seem, I need a way for a service method to access some data that is provided/set by attributes that are declared on the request DTO. If that is possible?

For example:

[MyAttribute(SomeOptions)]
public class RequestDto : IReturn<ResponseDto>
{
}

internal class MyService : Service
{
    public object Get(RequestDto request)
    {
        // Want to change what code executes here based on whether or not the 'request' variable for this method has [MyAttribute] defined on its DTO class or not. And if so, how to get any data provided to that attribute (or data provided by that attribute)
    }
}

OR should I be using a different approach to achieve the same thing?

I’d recommend against putting logic/filters on Request DTO’s (or reference any deps other than SS.Interfaces) so they can be re-used on the client. My preference is to put them on the Service or Action level.

The way to pass data throughout the Request Pipeline is to put them in the IRequest.Items Dictionary. Another solution is to have Request DTO’s implement a common interface which will let you share logic across multiple Request DTO’s. But otherwise if you put the Request Filter on the Request DTO you can just fetch it with:

var attr = typeof(RequestDto).FirstAttribute<MyAttribute>();

Good call. thanks
(I’m opting for placing attributes on the operations/actions/services and not the dtos)