.NET 6.0 中 EF Designer 的替代品是什么

Question

我在 .NET 框架 WPF 应用程序中成功使用了 EF。

现在我正在迁移到 .NET 6.0 wpf 应用程序，这里不可能使用 EF 设计器。

我所说的 EF Designer 的意思是：

自动生成的上下文 class 如下所示：

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);
    }

我不需要自己编写连接字符串的地方。

在哪里我也可以使用 Linq ：

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

那么是否有一个框架可以在 .NET 6.0 中完成所有这些工作？ 或者有没有办法在 .NET 6.0 中使用 EF 设计器？

Answer 1

不。EF Core 不使用设计器使用的 EDMX，并且没有新的设计器。 您可以在 .NET 核心中使用旧的 EF6，但 .NET 核心项目中不支持设计器。 您可以在单独的项目中使用设计器，并将生成的 DbContext 包含在您的 .NET 核心项目中。 请参阅https://docs.microsoft.com/en-us/ef/ef6/what-is-new/#ef-designer-support

但是 IMO 不值得使用旧的 EF 来保留设计师。

Answer 2

EDMX 不符合协作友好设计的趋势，因为开发和源代码控制越来越多地转向在线工具，并且越来越多的软件被开发为开源软件。 它在 EF 核心中被遗弃了（或者更好的是：没有重建）并且它不会很快回到那里 - 如果有的话。

即使只有两个人接触了源代码，这个单一的 EDMX 文件也是一场灾难。 我亲身经历过。 类似的巨石存在并被遗弃。 已经出现了其他设计/架构，允许以最小的合并冲突风险进行修改，例如垂直切片（顺便说一句，不仅仅是因为这个原因）。

你可能不同意，但根据我的经验，最好顺应这种趋势（如果你不能打败它们，就加入它们）。 不要试图找到类似的单一替代方案。 首先开始工作代码。 也许有迁移，但不一定（迁移也不是协作友好的）。 数据库脚本和 EF class 文件的同步维护一点也不难，而且当数据库变得更复杂时，IMO 是go的唯一方法。 新类可以由有用的工具（如EF Core Power Tools ）生成，然后手动重新生成或维护。

我们喜欢使用数据库项目作为单一的事实来源，它还可以在源代码控制中实现详细的更改跟踪（可以说比迁移要好得多）。