ProxyFactory should be extendible to allow other interfaces to be proxied

[amoorthaemer]

Hi,

I'm currently working on a solution to mask property values based on user's claims (roles and/or policies) something in the line of SQL Server's masking functionality. Currently it is no option to just target SQL Server, because I want it to be provider agnostic.

So, I had the idea to use Castle Dynamic Proxy for this, Which is a great tool, but as it is EF uses this already for lazy loading and friends. I took a quick look into the source code and quickly found out that using Castle is not an option because the ProxyFactory can't be easily extended and replaced by a derived one, unless I'm wrong and in that case a workable solution will be appreciated.

But, I figured it could be possible if the ProxyFactory was a bit more flexible. Not that I expect it to be fully customizable, but at the least it should accept additional interface types through a kind of interface plugin system. Those plugins should be registered as provider specific services and injected into the ProxyFactory's constructor,

The plugin could look something like this

public interface IInterfaceToProxyPlugin { Type InterfaceType { get; } IInterceptors[] Interceptors { get; } bool ShouldBeActivated { get; } }

public interface IInterfaceToProxy<T>: IInterfaceToProxy where T: class { Type InterfaceType => typeof(T); }

The ProxyFactory's constructor should then accept an IEnumerable<IInterfaceToProxyPlugin> and the methods that construct the proxies should take these new interfaces into consideration and add them when requested

I know this is just a rough idea, but I think it may add an additional layer of extensibility to EF that is functional and not too hard to implement

That is about it

Please let me know...

Best regards,

Bert

[ajcvickers]

@amoorthaemer You can create and use your own implementation of IProxyFactory, deriving from the EF Core default implementation or not as you choose.