我正在尝试在我的实体框架代码优先应用程序中构建一个类似于StackOverflow的徽章系统。
我总共会有大约10个徽章，每种徽章都有自己的属性。我想要有基类Badge并从基类派生其他类。
例如，会有 Sprinkle 徽章，如果他的帖子被喜欢3次或更多，它将自动分配给用户。因此，我将Sprinkle类具有附加属性NumberOfLikes（以便稍后可以更新）。但是，在数据库表中，此类只有一条记录。这不奇怪吗？
我将有10个这样的类，并且数据库中只有相应表的单个记录。我必须为每个类都有单独的类才能配置它们的唯一属性。
我的设计选择是否很差？
答案 0 :(得分：2)
您可以考虑区分徽章的业务规则，即在派生徽章类中编码的业务规则和用户获得的徽章的簿记。我认为没有必要让这个规则类成为实体框架类，并且如果它没有您想要经常更改的任何参数，则将它们存储在数据库中。您可以将此参数存储在其他配置存储（例如，exe.config）中，或者对其进行类似或硬编码。这个类的（可能只有一个）实例纯粹是为了执行业务规则。将它们视为服务（DDD）或可能是策略模式或（用于评估）访客模式。它们可以在不在数据库中存储/加载的情况下创建（可能是每个IoC / Di容器自动创建所有派生）。 另一方面，你必须预订哪个用户获得了哪个徽章（在每个请求中计算这个新版本可能会有性能损失）。这里有一个存储在数据库（1：n）中的类并存储用户收到的徽章列表是有意义的。因此，在每次更改（新帖子，新邮件，无论如何）或不时（夜间运行）之后，您都会浏览徽章规则类和用户尚未拥有的每个徽章（或者是否可以放弃批量为该用户执行以检查是否适用。如果是，则创建用户获得徽章的标记。
答案 1 :(得分：1)
在您的示例中，您可以在数据库中存储用户，他的帖子和喜欢的数量。 Sprinkle徽章可能是某些业务规则的结果（您的帖子（或用户）Sprinkle兼容）并且可能不会存储在您的数据库中？
在其他世界中，Sprinkle徽章是一种查看超过3个喜欢的帖子（或用户）的方法吗？
也许这个规则可以存储在你的数据库中并进行参数化？