Add resource removal to ChangeTracking

I suggest adding such a pattern to EF Core to remove unnecessary resources from ChangeTracker

using System;
using Microsoft.EntityFrameworkCore;

//Example Use
var myDb = new MyDbContext();
using var info = new Info();
myDb.AddInfo(info);
myDb.SaveChanges();

class MyDbContext:DbContext 
{
    public DbSet<Info> information { set; get; }
    public void AddInfo(Info info)
    {
        if(info is IChangeTrackingDispose<Info> change)
        {
            change.SetDbSet(information);
        }
        information.Add(info);
    }
}
public class Info : IChangeTrackingDispose<Info>
{
    public int Id {set;get;}
    public DbSet<Info> _dbSet { set; get; }

    public void Dispose()
    {
        (this as IChangeTrackingDispose<Info>).Close();
    }
}

interface IChangeTrackingDispose<T>:IDisposable where T : class
{

    DbSet<T> _dbSet { set; get; }
    public void SetDbSet(DbSet<T> dbSet)
    {
        _dbSet = dbSet;
    }
    private void RemoveFromChangeTraking()
    {
        ///The logic for removing this instance from Change Tracking
    }
    public void Close()
    {
        RemoveFromChangeTraking();
    }

}

[roji]

I’ve done my best to describe EF best practices, and how the product was designed to be used - the conversation seems to be going in circles at this point. I think that between the above and the EF documentation you should have all the information in order to write an EF program according to our recommended guidelines.

[Mr0N]

@Mr0N there really are no memory leaks here. Carefully read the above to understand that.

Well, I don’t know, it might be like that if you follow the documentation and make a scoupe context or use a factory, but in any case, if you make it a singleton, there will be problems, well, maybe so be it) but I’m not used to this) because .Net controls the use of memory, never- I wouldn’t have thought that the context of the database would violate it, that’s why there were some problems) well, I solved them