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

Question

我还没有接触过实体框架，因此我想听听一些有经验的人的意见。

我有一个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

关心命名是件好事！

如何做取决于你的应用程序的组成。假设你有一个网络应用程序来注册不明飞行物目击事件，举一些常见的例子。如果数据库中有单独的部分（可能是单独的架构）包含用户、角色和权限，则可以创建一个名为AuthorizationContext的上下文，并为业务部分创建一个名称为UfoDbContext的上下文。

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

有些人（我不是其中之一）喜欢为每个应用程序"列"（数据库到用户界面）或"用户故事"使用一个上下文。那么，有意义的名字就更重要了。

Answer 2

我的建议是使用指示命名中内容的东西。例如，您可以提取项目名称的一部分，并将其记为EDMX的名称。包括一些使其不那么通用的内容。

我也倾向于在命名中包含一个"Ef"，这是我在一个已经有ORM的项目中开始的。

举个微软的典型例子：如果你的项目属于Norwind的伞式名称，下面是我在模型项目中命名一些文件的方法：

EDMX文件：NorvindEfModel.edmx

生成器/TT文件：NorvindEfDbContext.tt

实体类：挪威实体

如果你从微软那里下载一个示例项目，我不能说微软会是这样的（尽管我相信它会很相似），但我认为这是一个合理的命名结构，符合我的需求。底线是，这在很大程度上取决于意见和你对具体区别的需求。