【发布时间】：2020-02-20 14:07:27
【问题描述】：
对于上下文，在 Unity3D 编辑器中使用 C#。
我越来越频繁地开始使用枚举将事物松散地耦合到设置。
例如，我正在设置一个项目，我想从一组已定义的视觉效果中为其提供视觉效果。该视觉对象基本上是一个包含精灵、颜色和附加到整数唯一 ID 的模型的类。从这个唯一 ID，我生成一个枚举。并且需要一些努力来验证 UniqueID 是否真的是唯一的，并捕获一些与此相关的边缘情况。
执行上述操作的好处是枚举是必须存储在项目上的所有内容，以将其链接到视觉对象。在运行时，会创建一个字典来查找枚举，然后请求加载/使用存储的视觉对象。这将视觉效果松散地耦合到项目，因此加载项目列表不会自动加载与项目关联的所有视觉资产。最后一部分是统一的默认行为，真的很烦人，而且这种默认行为确实会减慢游戏速度并消耗大量内存。
因此，我们有很多用于各种目的的枚举，并且发生了很多查找工作。目前我们对此没有什么大问题。
但是，枚举和这些枚举的编辑/生成容易出错，因为当值被删除时，项目（和任何其他相关方）不是更明智的，因此必须在构建之前进行测试，或在运行时遇到安全捕获/错误。
我的问题是。这是对枚举的公然滥用吗？如果是这样，解决这个松散耦合问题的更好方法是什么？ 如果不是，那么以安全的方式设置和管理这些枚举的更好方法是什么？因此，如果使用枚举的任何内容现在具有无效值，或者值的含义会改变，那么警钟就会响起？我想这几乎是不可能的，并且需要到处都有代码在重新编译时“自我检查”？
或者这一切都归结为团队纪律以很好地管理价值观，并了解枚举的含义和代表什么？在这种情况下，除非我为每一个都编写一个自定义编辑器，否则它永远无法让这个设计师变得友好。
感谢您提供的任何见解。
【问题讨论】：
-
也许为项目和图形组合使用一个小型数据库？ （例如使用 sqlite 或 litedb）我认为“链接表”（只是图形的 UID 和每行项目的 UID）会更有效（并且您可以创建一个更动态的系统）。
-
@HeadhunterXamd 这实际上可能是一个很好的建议，尤其是对于查找而言。但这也意味着不是生成枚举（目前只是一个简单的方法，它需要一个名称和一个要生成的 int/string 对列表）必须实际删除/重建表。但是，它不能解决设置/更改的问题。或者至少它和现在的枚举一样。
-
此外，项目将随机生成，因此它们本身并没有真正的唯一 ID。让这个查找变得更难处理。
-
没错，但我认为通过一些小的调整，对于随机生成的资产，DB 比 Enum 更好。主要是因为那时你可以自动化（几乎）一切。此外，如果您有数据库，您可以自动检查丢失的资产。并删除相应的行以防止出现一些错误。
-
这又不会对工作流程有太大改善。例外是数据库可能会生成一个日志，告诉我们从其他表/链接中删除了哪些引用。问题是，如何添加一个表格，将视觉效果链接到运行时唯一生成的项目？只需为它们生成一个哈希值并希望它们永远不会发生冲突？
标签： c# unity3d enums uniqueidentifier loose-coupling