Stuck at creating a migration BCL with the least amount of boilerplate code?

[Nefcanto]

I reported my problem as an issue: #106916

I want to create a migration BCL (base class library). The migration BCL should be clean and have as little boilerplate code as possible.

It is expected for users to create classes, inherit from Migrator, and have access to all methods related to the database:

public class UserMigrator : Migrator
{
    public void Migrate()
    {
        // Here we need to have access to everything related to the migration. This is a portion of the methods we need to inheit:
        // Run
        // RunIf
        // GetList
        // GetEntity
        // HasResults
        // HasDatabase
        // HasTable
        // RenameTable
        // DropTable
        // HasColumn
        // HasColumns
        // AddColumn
        // ModifyColumn
        // DropColumn
        // SetAsPrimaryKey
        // RunIfHasColumns
        // HasView
        // DropView
        // ...
    }
}

As you can see, there are many methods. This makes the Migrator.cs a God object. So we intend to break it into meaningful packages (maybe Interface Segregation Principle):

1. DatabaseMigrator
2. TableMigrator
3. ViewMigrator
4. ColumnMigrator
5. DataMigrator
6. ...

So we divide a file with thousands of lines into multiple files, each with fewer than a thousand lines and each about a specific database object.

Yet, we end up with a new problem. How to join them back in the Migrator class? We don't have multiple inheritance in C#. We don't have mixin, we don't have traits.

So, one possible solution could be that we change them all into interfaces, and then use the default interface methods:

1. IDatabaseMigrator
2. ITableMigrator
3. IViewMigrator
4. IColumnMigrator
5. IDataMigrator
6. ...

But then we end up with this problem that second-level inheritors won't be able to access these default methods:

UserMigrator : Migrator : IColumnMigrator

The HasColumn is not accessbile in the UserMigrator class.

And if we try to explicitly implement each method in the Migrator class:

public bool HasColumn(string database, string table, string column) => ((IColumnMigrator)this).HasColumn(database, table, column);

We end up with stack overflow.

If we try to use DI, then we won't be boilerplate-free:

public class UserMigrator : Migrator
{
    private readonly IColumnMigrator _columnMigrator;

    public UserMigrator(IColumnMigrator columnMigrator)
    {
        _columnMigrator = columnMigrator;
    }

    public void Apply()
    {
        if (_columnMigrator.HasColumn("UserId"))
        {
            Console.WriteLine("I am UserMigrator. Column UserId is already added.");
            return;
        }
        // adding UserId column
    }
}

A lot of boilerplate, with no value in this context.

What architecture would solve this problem? If C# had a simple mixin or trait syntax, we would do it this way:

public class Migrator
{
    trait DatabaseMigrator;
    trait TableMigrator;
    trait ViewMigrator;
    trait ColumnMigrator;
    ...
}

[huoyaoyuan]

As I replied in dotnet/csharplang#8075 and other threads, there's no direct support for compositing types with method-sets. Using default interface methods is a workaround, but you do need to know the difference and pay attention to interface methods.

As explained in #106916, there are three key differences when declaring methods inside interface context: they are virtual by default, will be "overridden" by default, and not included in-scope in derived context. The first two points can be mitigated by applying sealed on the methods. The third point is limitation of the languages.

[Nefcanto]

@huoyaoyuan, thank you for the explanation both here and in the issue. However, in this question, I'm trying to seek help for designing this BCL. What options do I have to make this library as clean as possible for the end users?

1. They should be able to use the entire BCL using a simple : Migrator inheritance
2. The Migrator.cs should be split into multiple files (not for the sake of reusability or DRY, but for the sake of maintenance)
3. They should be put back into the Migrator.cs class

What options do I have?

[huoyaoyuan]

If you can ship the code as source files instead of compiled assemblies, then partial should be a good correct approach. partial types can be re-assembled differently in different projects. The AOT compilers for NativeAOT/R2R are using this approach.

Another workaround is going with multiple-inheritance with interfaces, and provide some helper methods as extension methods to avoid casting to the interface:

public interface Interface1
{
    public sealed void InterfaceMethod1()
    {

    }
}

public static class Interface1Extensions
{
    public static void InterfaceMethod1(this Interface1 self) => self.InterfaceMethod1();
}

Derived classes still need speak this.InterfaceMethod1 instead of InterfaceMethod1 directly, but it's easier now.