Eff, Aff and Entity Framework Core

[timmi-on-rails]

I am experimenting with adopting the Runtime approach (https://github.com/louthy/language-ext/wiki/How-to-deal-with-side-effects) in an Entity Framework Core project.

So far I have a demo project together with a library and code generation (source generators) project.

I am interested in your opinions before going further.

As starting point, here is some regular EF Core code for a table of products:

public class AppDbContext : DbContext
{
    public DbSet<Product> Products { get; private set; } = null!;

    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options)
    {
    }
}

public class Product
{
    public int Id { get; init; }

    public string? Name { get; init; }
}

Now comes the new thing.
As an example we create a database initialization routine:

using static Demo.GeneratedAppDbContext;

static Aff<RT, Unit> InitializeDatabase<RT>()
    where RT : struct, HasDbContext<RT, AppDbContext>
    => from _1 in Database.EnsureDeleted<RT>()
       from _2 in Database.EnsureCreated<RT>()
       from _3 in Products.Add<RT>(new Product { Name = "Laptop" })
       from _4 in SaveChangesAsync<RT>()
       select unit;

The class Demo.GeneratedAppDbContext is auto-generated from the AppDbContext and its DbSets.
The trait HasDbContext is new and actually, together with the runtime RT, the only thing that has to be implemented by hand.

So here is the trait:

public interface DbContextIO<TDbContext>
    where TDbContext : IDisposable
{
    TDbContext CreateDbContext();
}

public interface HasDbContext<RT, TDbContext> : HasCancel<RT>
    where RT : struct, HasCancel<RT>
    where TDbContext : IDisposable
{
    Eff<RT, DbContextIO<TDbContext>> DbContextEff { get; }
}

The trait implementation is simple:

public readonly struct AppDbContextIO : DbContextIO<AppDbContext>
{
    public readonly static DbContextIO<AppDbContext> Default =
        new AppDbContextIO();

    AppDbContext DbContextIO<AppDbContext>.CreateDbContext()
    {
        var opts = new DbContextOptionsBuilder<AppDbContext>().UseSqlite("Data source=_test.sql").Options;
        return new AppDbContext(opts);
    }
}

That's it!
I don't want to explain the details of the implementation, yet.
And there are a lot of minor decisions to make, before this should go online.
But I hope the basic idea has become clear.

What do you think?

[bmazzarol]

@timmi-on-rails I think it depends a little on what operations you are supporting in your static Database module.

Would you be able to share a little bit of that?

Some things that I tend to need are,

• Support for transactions
• Support for execution strategies (not sure these are required with the tools we have for retry on Aff)
• Ability to construct multiple DbContexts to run queries in parallel
• Standard Add,Update,Delete and Select on DbSets
• Adhoc SQL
• Access to Commands to run procedures
• Vendor specific operations (Oracle, SqlServer, Cosmo)