我首先使用EF 5进行迁移和代码。这一切都很有效，但我想解决一些问题/问题。
让我们从一个简单的例子开始。假设我有一个User表和一个用户类型表。用户类型表是我的应用程序中的枚举/查找表。因此，用户表具有UserTypeId列和UserType的外键引用等。在我的poco中，我有一个名为UserType的属性，它具有枚举类型。
要将初始值添加到UserType表（或稍后添加/更改值）并在初始迁移器等中创建表。我需要一个UserType表poco来表示数据库中的实际表并在地图文件。我将User poco中的UserType属性映射到UserType poco中的UserTypeId。所以现在我有一个poco代码优先/迁移/上下文映射等，我有一个枚举。两者的名称不能相同，那么我是否有一个名为UserType的poco和枚举的其他内容，或者UserType的poco是UserTypeTable还是什么？
但更重要的是，我是否错过了代码首次运行的一些关键因素？我尝试了上面的示例，运行了Add-Migration，但它没有为枚举添加查找表。
答案 0 :(得分：2)
如果我理解你的问题以及你对此感到困惑，
Enums support has nothing to do with lookup tables on the Db side.
Enums只是允许你在你的类中拥有Enum-s的属性，并且基本上被转换为'int'-s - 所以那里没有其他东西。
有关详细信息，您可以查看Julie Lerman on Enum-s support
中的视频希望这会有所帮助
答案 1 :(得分：0)
根据我的经验，枚举对于您的代码比查找类更重要，因此请为其指定正确的名称。我也会保持查找类与我的模型中的用户没有任何关系。如果它仅用于查找，那么您不需要将其挂在用户之上。带DescriptionAttribute的枚举可以在代码中完成查找。
UserTypeLookup可能是一个好名字，因为这听起来就像你将要使用它。然后，您可以使用该类来维护表。
假设您没有首先在ef代码中映射UserTypeLookup和User之间的关系，那么您需要手动在DB中创建的唯一内容是{{1}之间的foriegn密钥关系您UserType表中的列和User表中的PK。 UserTypeLookup仍然可以是实体，即使您没有为它设置任何关系，EF仍应为其生成数据库表。