实体框架：EDMX文件和实体类的命名约定/建议？

Question

我还没有与Entity Framework进行太多联系，因此我希望听到一些有经验的人。

我有一个MVC项目，我的DataAccess位于一个不同的项目中，我想放置我的EDMX文件。

那我该如何命名这个文件呢？默认情况下它是“Model1.edmx”，但在MVC的上下文中，我对这个名称感到不舒服。它真的是一个模特吗？ 我倾向于将其称为“DbModel”或其他东西，以表明它与数据库相关的东西。

你们怎么称实体班？我想我喜欢EF的典型名称“DbContext”。

所以在我的控制器中我会有像

这样的东西

public class WorldController : Controller
{
    DbContext db = new DbContext();

    public ActionResult Own()
    {
        var allContinents = db.Continents;
        [...]
    }
}

很抱歉挑剔，但我确实非常关心命名。

Answer 1

关心命名很好！

如何操作取决于您的应用程序的组成。假设您有一个用于注册UFO目击的Web应用程序，可以命名常见的东西。如果存在包含用户，角色和权限的数据库的单独部分（可能是单独的模式），则可以创建名为AuthorizationContext的上下文，并为业务部分创建名为UfoDbContext的上下文。

我的意思是，如果有明确的聚合没有或没有重叠，你可以为它们创建具有明确名称的单独上下文。如果一个上下文符合该法案，我仍然会给它一个与您的应用程序域相关的有意义的名称（而不是DbContext）。

有些人（我不是其中之一）喜欢使用每个应用程序“列”（db到UI）或“用户故事”的一个上下文。有意义的名字甚至更重要。

Answer 2

我的建议是使用指示命名内容的东西。例如，您可以参考项目名称，并将其下载到EDMX的名称中。包含一些不那么通用的东西。

我也倾向于在我的命名中包含一个“Ef”，这是我在处理已有ORM的项目时开始的。

采用微软的原型示例：如果您的项目属于Norwind的名称，我将如何命名模型项目中的一些文件：

EDMX档案： NorwindEfModel.edmx

生成器/ TT文件： NorwindEfDbContext.tt

实体类： NorwindEntities

我不能说如果你从他们那里下载了一个示例项目，这就是微软的确切方式（尽管我相信它会类似），但我认为这是一个合理的命名结构，它符合我的需求。最重要的是，这主要取决于意见和您对特定区别的需求。