是否在 ASP.NET Core Identity AspNetUsers 表中存储用户设置答案

【问题标题】：Store User Settings in ASP.NET Core Identity AspNetUsers Table or Not是否在 ASP.NET Core Identity AspNetUsers 表中存储用户设置
【发布时间】：2019-09-01 00:41:20
【问题描述】：

我正在使用 ASP.NET Core 设置一个 Web 应用程序，并通过 Identity Framework 进行身份验证。快速提问。我正在存储有关用户的各种数据，例如他们的地址、帐户设置、订阅状态和到期日期等。我最好通过创建继承 IdentityUser 的 ApplicationUser 类将所有这些数据存储在 AspNetUsers 表中，还是应该保留该表用于登录/安全信息并创建另一个表来存储仅与我的应用程序相关的数据，并且这两个表之间存在一对一的关系？

【问题讨论】：

还有一点需要考虑的是 GDPR。我喜欢将用户提供的数据与通过其他方式收集的用户数据分开。这样，当/如果您的用户选择删除他们的所有信息时，他们只会删除他们提供的信息。

标签： c# .net asp.net-mvc asp.net-core

【解决方案1】：

始终是单独的表/类。

复杂性随着应用程序的增加而增加。桌子会变得太大，然后你会花时间远离它。我们在旧版应用程序中也有类似的情况，其中一个组织已经增长到 70 多个列。我在 Twitter 上听到过关于有类似经历的人的故事。

除此之外，您还可以考虑单一职责。鉴于一个单一的更改原因 - 或更多鲍勃叔叔更新的定义"A module should be responsible to one, and only one, actor"。

您最终可能会根据module 进行设置 - 您添加的越多，它就会变得越大。当然，请等到以后再进行更改 - 但这永远不会发生。

对我来说，身份是它自己的系统。不是你的系统。它提供了一种身份验证机制。它使用用户类中的able或字段中的大多数列来执行此操作。

您的设置是关于您的应用程序的 - 这是您的域。如果您替换Identity，您可能会替换该用户表/用户类。那么你的设置会在哪里结束呢？

【讨论】：

当我将字段从 ApplicationUser 移动到 Customer 时，我意识到了另一件事：并非所有用户都是客户！我的管理员帐户不需要客户信息。