ASP.NET MVC登录用户「添加到收藏」功能实现方案咨询

一、数据库中间表方案：不存在重复数据问题，是长期存储最优解 #

• 你担心的重复数据是误解，多对多关联的中间表仅存储用户ID和影片ID两个外键字段，每条记录对应一个用户的单条收藏关系，数据量极小且无冗余，是行业标准的多对多场景设计方案。
• 该方案天然满足长期存储需求：数据持久化保存，用户更换设备、清除浏览器数据后收藏仍可保留，支持主动删除操作，还能方便扩展后续功能（比如统计热门收藏影片）。
• 实现成本低：在EF中配置User与Movie的多对多关联，框架会自动生成中间表，增删收藏仅需操作关联关系即可。

二、非数据库方案的可行性与局限 #

1. Cookie 可实现收藏功能，但有明显短板 #

• 确实可以设置最长1年的有效期，满足长期存储需求，但需注意：
  • 容量限制：单个Cookie最大仅4KB，若收藏的影片ID为整数类型，最多可存储几百条，数量超限后会失效。
  • 安全风险：Cookie存储在客户端，容易被篡改，若要防范伪造，需对存储的ID列表做签名加密（比如用MachineKey处理），会增加开发复杂度。
  • 性能损耗：Cookie会随每次请求发送至服务器，若收藏列表较大，会额外增加请求体积。

2. Session 仅适合临时收藏场景 #

• Session默认有效期约20分钟（可配置更长，但服务器重启或Session回收后数据会丢失），仅能满足用户当前会话内的临时收藏需求，无法实现长期保留。

3. 分布式缓存（如Redis）：适合半持久化场景 #

• 可将用户收藏列表存入Redis并设置较长过期时间，相比Cookie更安全、存储容量更大，但可靠性不如数据库——缓存可能因内存不足、服务重启丢失数据，更适合作为数据库方案的缓存补充，而非替代方案。

三、收藏夹页面跳转逻辑：与存储方案无关，无额外复杂度 #

无论采用哪种存储方案，收藏夹页面只需展示影片ID、标题等基础信息，点击跳转详情页仅需生成对应影片ID的URL，通过RedirectToAction或直接跳转静态URL即可完成，逻辑完全一致，不会因非数据库方案增加复杂度。

内容的提问来源于stack exchange，提问作者Gunars