lawrence-laz/decor.net

A simple way to decorate a class with additional functionality using attributes.

Hi there 👋

decor.net's Issues

Add tests for typed http clients

Typed http clients are registered to ServiceCollection using .AddHttpClient<T>() and .AddHttpClient<T1, T2>() methods. Add tests making sure that these cases are covered and decorators work as expected.

MethodDecoratorMap - Method Dictionary Filter Flexiable

Duplicate of #15

Call a decorated method through reflection

Add TypeExtensions.IsDecorated()

There should be an easy way to check if a specific type is decorated.
Notice that this has to check the full hierarchy and not just the current type.

Api could be a simple extension method:

bool isMyClassDecorated = typof(MyClass).IsDecorated();

Support decorating open generics

Currently decorating open generic service descriptions is impossible. Example:

services.AddTransient(typeof(ISomeService<>), typeof(SomeService<>)).Decorated();

Vulnerability in Castle.Core 4.4.0

Hello, we're using this great package and our scanning tools have picked it up that it has vulnerability.

Basically nuget that is being used in this project (Castle.Core 4.4.0) has reference to this vulnerability: CVE-2018-8292

Exact path: Decor.Extensions.Microsoft.DependencyInjection/2.0.7 -> Castle.Core/4.4.0 -> NETStandard.Library/1.6.1 -> System.Net.Http/4.3.0

We believe that by bumping Castle.Core to newer versions (>= 5.0.0) should fix this issue.
Same issue being discussed in Castle.Core: CastleCore using an old version of System.Net.Http which is vulnerable

Could this be done and released?

Thanks in advance!

Make sure non-async Task<T> methods can be decorated

Cannot Instantiate Object Because Parameterless Constructor is Missing

User reported an issue of being unable to create a decorated object instance without parameterless constructor.

Reproduced here:

using Decor;
using Microsoft.Extensions.DependencyInjection;
using System.Threading.Tasks;
using Xunit;

namespace Reproduce
{
    public class DecorRepro
    {
        public class Dependency { }
        public class Decorator : IDecorator
        {
            public async Task OnInvoke(Call call) => await call.Next();
        }
        public abstract class Base
        {
            protected Base(Dependency featureToggle)
            {
            }
            public abstract Task OnMessage();
        }
        public class Actual : Base
        {
            public Actual(Dependency featureToggle) :base(featureToggle)
            {
            }

            [Decorate(typeof(Decorator))]
            public override async Task OnMessage() => await Task.Delay(1);
        }
        [Theory, AutoMoqData]
        public void aaa(ServiceCollection serviceCollection)
        {
            var provider = serviceCollection
                .AddDecor()
                .AddTransient<Dependency>()
                .AddTransient<Decorator>()
                .AddScoped<Actual>().Decorated()
                .BuildServiceProvider();
            var sut = provider.GetService<Actual>();
        }
    }
}

Change IDecorator to Act Like an Interceptor

public interface IDecorator : IBaseDecorator
{
    void OnBefore(CallInfo callInfo);
    void OnAfter(CallInfo callInfo);
}

Currently decorator consists of two methods OnBefore and OnAfter. This seems like an intuitive way to approach additional functionality. However, this approach is a bit limiting, as it:

1. Does not allow to suppress target method invocation. This would be useful in caching situations.
2. Does not allow to catch exceptions, or retry method call. This would be useful for Polly like decorator.
3. Transferring state between OnBefore and OnAfter is a bit complicated. You cannot just set a property in a decorator class, because it might get overwritten. For this CallInfo.SetState(object) and CallInfo.GetState<T>() was introduced.

class SomeDecorator : IDecorator 
{
    void OnBefore(callInfo) => callInfo.SetState(Stopwatch.StartNew());
    void OnAfter(callInfo) => callInfo.GetState<StopWatch>().Stop();
}

Having a decorator work more like an interceptor would eliminate the need of these state methods as you could just use local variables.

The suggested decorator would look something like this:

interface IDecorator 
{
    Task OnInvocation(Invocation invocation);
}

class SomeDecorator : IDecorator 
{
    async Task OnInvocation(Invocation invocation) 
    {
        try
        {
            var stopwatch = Stopwatch.StartNew();
            await invocation.Proceed();
            stopwatch.Stop();
        }
        catch (Exception)
        {
            // Uh-oh...
        }
    }
}

Consider Removing IDecoratorProvider in a Favor of Func Factory

public interface IDecoratorProvider
{
    IBaseDecorator Get(Type decoratorType);
}

This interface is used when integrating with dependency container. However, there's is nothing special about it that couldn't be replaced with a simple Func<Type, object> factory method. The latter option seems simpler. I would also consider removing IBaseDecorator then.

Consider removing this interface in the next major version.

Feature Request: Customize Method Selection in MethodDecoratorMap Without Using Attributes

Hello,

In our project, we want to use MethodDecoratorMap or a similar structure and choose the method here with a more dynamic approach instead of using attributes. Currently, we need to add an attribute like [Decorate(typeof(MyDecorator))] to each service method. However, instead of this alternative, methods are automatically selected and the decorator is displayed based on a certain standard of criteria (e.g. all methods marked as public and virtual).

Recommended Solution:
As a suggestion, I suggest adding a mechanism in MethodDecoratorMap or similar structure where method selection can be made via a user-supplied function or lambda description. This will allow us to automatically select methods and attributes according to a given set of rules, rather than manually changing attributes, especially in large projects.

An example usage scenario:

services.AddMethodDecoratorMap(config => {
      config.IncludeMethods(method => method.IsPublic && method.IsVirtual);
});

This feature provides great convenience in our project and other projects that work similarly. It will allow users to have a more flexible and dynamic pace, while also making the code easier to read and maintain.

Thank you for your support and contributions.