Gateway Class Source Generator

[TheCakeMonster]

I'm wondering whether we can use a source generator to create implementations of the classes we will need to interact with business objects, if we are to step away from static factory methods. At the moment I'm calling these new classes gateways, to differentiate them from the object factories used in the Factory Implementation data access pattern, but that's a separate discussion I've raised elsewhere - see Discussion 2964.

There's an argument to say that defining an interface for our business object gateways enables better testability. I'm sure those who are keen on per-class unit testing (a very granular testing approach) would want this to be the case, as mocking against an interface is something they are very used to. However, creating an interface and an implementation is more code.

It would be convenient to be able to define an interface and not create the implementation at all, instead having the implementation created for us by a source generator. That gives us maximum bang - a strongly typed contract for our consumers - for minimum buck - the least code possible.

Note that all of the naming in the sample code included is merely indicative at this stage.

A compatible interface would look something like the following:

[Gateway]
public interface IPersonGateway
{
	Task<Person> CreatePersonAsync();

	Task<Person> FetchPersonAsync(string personRef);

	[Criteria(typeof(ExternalRefCriteria))]
	Task<Person> FetchExternalPersonAsync(string externalPersonRef);
}

The generated code for this interface would be something like:

public partial class PersonGateway : IPersonGateway
{
	private readonly IDataPortal<Person> _dataPortal;

	public PersonGateway(IDataPortal<Person> dataPortal)
	{
		_dataPortal = dataPortal;
	}
	
	public async Task<Person> CreatePersonAsync()
	{
		return await _dataPortal.CreateAsync();
	}

	public async Task<Person> FetchPersonAsync(string personRef);
	{
		return await _dataPortal.FetchAsync(personRef);
	}

	public async Task<Person> FetchExternalPersonAsync(string externalPersonRef);
	{
		return await _dataPortal.FetchAsync(new ExternalRefCriteria(externalPersonRef));
	}
}

There is some complexity in the implementation of this source generator. The main one is the Criteria attribute, which I am suggesting to support the use of Criteria objects to enable differentiation where multiple data access methods exist. We would need a custom attribute for this purpose to enable access to the data it exposes, and as we have learned that attribute cannot live in the Csla assembly, as the Csla assembly is not a .NET Standard 2.0 assembly in all circumstances.

The other implementation detail is the use of synchronous or asynchronous methods. This is something the source generator would need to be able to recognise. I think that's possible, but it is an unfortunate complexity that it would be nice to sidestep, if possible - at least for the first implementation. We could do so by supporting only async to begin with, or by creating two separate source generators. Creating two separate source generators would reduce flexibility - you wouldn't be able to mix and match sync and async in the same interface.

Remember that the code created by source generators cannot be edited, so you would not be able to modify the implementation unless you omitted the attribute and wrote the whole implementation yourself. How often do you think you would need to use alternate code in these methods?

How useful would people find this?