What is the replacement for EF Designer in .NET 6.0

Question

I am sucesfully used EF in .NET framework WPF app.

Now I'm migrating to .NET 6.0 wpf app and it's impossible to use the EF designer here.

What I mean by EF Designer is:

Automatically generated context class like following:

public partial class NEVA_TELECOM_DBEntities : DbContext
{
    public NEVA_TELECOM_DBEntities()
        : base("name=NEVA_TELECOM_DBEntities")
    {
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        throw new UnintentionalCodeFirstException();
    }

    public virtual DbSet<Position> Positions { get; set; }
    public virtual DbSet<Employee> Employees { get; set; }
    public virtual DbSet<Event> Events { get; set; }
    public virtual DbSet<sysdiagram> sysdiagrams { get; set; }
    public virtual DbSet<AvailableModule> AvailableModules { get; set; }
    public virtual DbSet<Абоненты> Абоненты { get; set; }
    public virtual DbSet<Заявки> Заявки { get; set; }

    public virtual ObjectResult<string> sp_GetEmployeePosition(string number)
    {
        var numberParameter = number != null ?
            new ObjectParameter("Number", number) :
            new ObjectParameter("Number", typeof(string));

        return ((IObjectContextAdapter)this).ObjectContext.ExecuteFunction<string>("sp_GetEmployeePosition", numberParameter);
    }

Where I don't need to write connection string myself.

And where I can use Linq as well:

(from p in db.AvailableModules 
 where p.Access_Code == AcessCODE 
 select p.Available_Module).ToList();

So is there a framework that can do all this stuff in .NET 6.0? Or is there a way to work with the EF Designer in .NET 6.0?

Answer 1

EDMX doesn't fit in a trend toward collaboration-friendly design that has been going on since development and source control have moved more and more toward online tooling and since more software is being developed as open source. It was abandoned in EF core (or better: not rebuilt-in) and it won't come back there any time soon - if ever.

This monolithic EDMX file was a disaster even if only two people touched the source code. I've experienced it myself. Similar monoliths existed and were abandoned. Other designs/architectures have emerged that allow modifications with minimal risk of merge conflicts, for example vertical slices (not only for that reason, by the way).

You may not agree, but it's also my experience that it's better to move along with such trends (if you can't beat them, join them). Don't try to find a similarly monolithic alternative. Start working code-first. Maybe with migrations, but not necessarily (migrations aren't collaboration-friendly either). Synchronous maintenance of database scripts and EF class files isn't hard at all and IMO the only way to go anyway when the database gets more complex. New classes can be generated by useful tools like EF Core Power Tools and regenerated or maintained manually afterwards.

We like to use database projects as single sources of truth that also enable detailed change tracking in source control (arguably much better than migrations).