Discussion/ Proposal: Generic mechanism for delegator and proxy pattern

[georgiuk]

Problem

The scope is to have a generic mechanism to implement delegator/proxy/facade pattern (I am not sure about the exact name). I don’t know if this is already proposed and rejected, as I have seen some related proposals. Maybe additions in the runtime are also needed to implement it.

Today to implement a proxy you have to use either Remoting or some other library (such as DynamicProxy) that normally use the Emit namespace with its ovehead. Additionally custom framework implementations, such as ORMs and business layer/ domain frameworks, need deeper integration with the CLR and the language. Features that such frameworks provide include lazy loading, thread safety, caching, change tracking, etc. These are commonly built at the getter and setter methods of the properties, as properties correspond normally to data fields. In our custom framework implementation (named ODOS) we have a code generator that generates the properties in a separate partial class with the corresponding code.

Proposal

Instead of having the code generation overhead and boilerplate code, it would be nicer if I could just write automatic properties and method signatures and the compiler will generate the IL code needed to forward the calls to the implementation that my framework have provided. My proposal needs an additional CallerMemeber attribute, as is also proposed at the "Expand Supported Caller Info Attributes" issue #87 . It is also related to code generation proposals #107 and #341 .

So an interface named IDelegator should be added

public interface IDelegator
{	
	void PropertySetter(object instance, PropertyInfo propInfo, object parameter);
	object PropertyGetter(object instance, PropertyInfo propInfo, string propName);
	object RunMethod(object instance, MethodInfo methodInfo, params object [] parameters);
}

And an attribute named DelegatedAttribute.

Then maybe I have a framework class that implements the IDelegator interface. The users of the framework extend this class. The DelegetedAttribute is also (optionally) extended.

public class MyFrameworkEntity : IDelegator
{
	public void PropertySetter(object instance, PropertyInfo propInfo, object parameter)
        {
               // .....
        }
        public object PropertyGetter(object instance, PropertyInfo propInfo)
        {
               // .....
        }
	public object RunMethod(object instance, MethodInfo methodInfo, params object [] parameters) 
        {
               // .....
        }
}

public class MyFrameworkMember : DelegatedAttribute
{}

And then some user of the framework writes an extension to the base framework class

Class MyUserClass : MyFrameworkEntity
{
	[MyFrameworkMember]
	public int ID {get;}

	[MyFrameworkMember]
	public string Company {get;set;}

	[MyFrameworkMember]
	public float GetSalary(int year);
}

The compiler then will generate the required code to forward the calls

Class MyUserClass : MyFrameworkEntity
{
	[MyFrameworkMember]
	public int ID 
        { 
                get { return PropertyGetter (this, [CallerMember] member); }
        }

	[MyFrameworkMember]
	public string Company 
        {
                get {return PropertyGetter (this, [CallerMember] member);} 
                set {PropertySetter (this, [CallerMember] member, value);}
        }

	[MyFrameworkMember]
	public float GetSalary(int year)
        {
               return RunMethod(this, [CallerMember] member, year);
        }
}

The addition to the language syntax will be the allowance of non-abstract signature-only method statements when they are decorated with the specific attribute "DelegatedAttribute" (or a subclass of it).

The implementation itself except of the same class could live also in another class in a TypeDescriptor/ TypeDescriptionProvider like implementation. In fact the whole concept could be integrated in the TypeDescriptor itself.

[iam3yal]

@georgiuk Related #862 but really as you point out in your post this is yet another use-case for #341.

[georgiuk]

Although what I would like is to eliminate the code generation step and also to have the minimal impact on language syntax. I am not sure that code generation should be the answer to all these use cases especially for metaprogramming ones.

[georgiuk]

As #1096 I would like to resurrect this issue. As we have a framework on top of .NET, ODOS , we seek for solutions that will eliminate boilerplate code as well as provide constraints on the usage of special-framework managed properties and methods. These special properties and methods must have a specific implementation that the user "shouldn't" change. So I don't think that the solution for this is generating all the boilerplate code and then building code analysis tools so as to decide that the user have coded the body as supposed to. Additionally C# Properties is a fantastic language feature that should be further exploited and this is a great way.

I have created a small gist with a naive implementation of how could this work by using only attributes here. I suppose code generation in compile step based on attributes is not normal, so I guess a special keyword in combination with the attribute would be better. I would prefer the "delegated" keyword but it would confuse with the delegate, so maybe another keyword like "proxied" would be better.

I think this pattern would also help to build remoting like proxies without Reflection.Emit and AOP.