【问题标题】:When to use Enums with Entity Framework?何时在实体框架中使用枚举?
【发布时间】:2014-02-23 12:50:30
【问题描述】:

我已将枚举添加到我的C# Entity Framework 6, MVC 4 application。我喜欢这种方法:

  1. 我认为我的模型很清楚该值来自查找。
  2. 我可以使用以下方法轻松地将它们绑定到我的视图中的选择列表:examples from Stack Overflow
  3. 我不是在查找数据库来获取值。
  4. 我使用这些值的管道代码较少。

不利的一面是,我认为:

  1. 我需要小心保持数据库与实际查找表的代码同步。
  2. 我想,每次对代码进行更改时,我都需要部署代码,而不是使用“管理”表,用户可以在其中添加新的查找值。 (我想您可以有选择性,不要将枚举用于会发生很大变化的值)。

我只是想知道这种方法的真正优势是什么,是否有一些我想避免的常见情况?

谢谢

【问题讨论】:

  • 从不。您与数据库的绑定代码。现在可能看起来是一件好事,但在一个等待潜在发生的灾难的团队环境中。当数据库中的数据发生变化时不得不重新部署是可怕的。
  • 感谢 Jammer,是的,我正在采用这种思维方式。

标签: c# entity-framework enums


【解决方案1】:

我认为您的问题根本与 EF 无关,它与后端无关。

唯一真正的问题是您已经提出的建议 - 当您需要添加/删除值时必须重新编译。但是,这完全取决于您实际期望列表更改的频率。

从开发人员的角度来看,使用enum 的目的是为了可读性和简单性,但是,如果您 enum 真的只是为了 UI 目的,我认为您最终可能会给开发人员更多的维护工作清单比一次做很多工作而不必再担心。

为了给用户添加一个新选项而不得不重新编译对我来说似乎很脆弱。

【讨论】:

  • 谢谢詹姆斯,是的,我同意。我想我会谨慎地使用他的方法,从非常静态的列表(如果有的话)。
  • 我真的不会全部使用。问题是无数的,远远超出了评论的范围。此外,虽然只针对已知需求进行开发是一种很好的做法,但不应排除未来的需求并将自己描绘成一个困难的、可能容易出错且在以后需求发生变化时更改成本高昂的角落。
  • @Jammer 您有权发表您的意见,但是,在我看来,未来的校对是第二要务;让事情正常工作是始终的第一要务,如果使用enum 做到这一点,那么一定要使用它。但是,我同意(正如我的回答所暗示的那样),您确实需要权衡您正在做的事情的未来影响以及从长远来看是否值得。这就是为什么我不一定建议不要这样做,因为实际上它会完成这项工作......相反,在你做之前先考虑一下。
猜你喜欢
  • 2010-12-04
  • 1970-01-01
  • 1970-01-01
  • 2015-06-02
  • 2012-04-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多