设计徽章系统,在哪里解雇业务逻辑？在代码或存储过程中？或两者？

Question

如果你要构建一个类似于SO的徽章系统,你会直接将逻辑/业务层放在数据库中(通过存储过程,预定的sql作业)还是将它放在服务器端？

从我能想到的,你必须:

1. 列出与当前用户操作相关的徽章
2. 检查用户是否已经拥有徽章
3. 为用户插入徽章

潜在的选择

1. 调用存储过程等的Web应用程序中的业务逻辑
2. 仅存储过程
3. 每隔x分钟运行一次的SQL Server作业
4. 每隔x分钟运行一次的Windows服务

是否需要这些组合？我认为,因为一些徽章是基于给定问题的里程碑,也许批量工作更好？

更新

您可以修改徽章系统,然后为每个人重新运行整个徽章链接的系统会更好.也就是说你改变了一些徽章的逻辑,现在你必须将它重新应用到所有的问题/答案/投票/等.

有趣的问题要解决!!

Answer 1

我建议将所有业务逻辑放在业务层中.我推荐这个有几个原因:

• 将业务逻辑保持在一种语言/位置
• 可伸缩性 - 您可以对数据进行分区,实现不同的缓存机制等.
• 关注点 - 让你的数据库做它最擅长的事情......存储数据,让你的编程语言决定数据.

Answer 2

我会把它放在业务层,毕竟这是我们正在讨论的业务逻辑.存储过程当然可以用来取回适当的数据,但我不是仅仅在数据库中实现决策逻辑的粉丝.如果不是因为在以后重新访问代码时变得越来越难以跟踪正在发生的事情.

Answer 3

就个人而言，我会离开数据库来进行数据存储/检索，并将逻辑置于“业务层”中。

在 StackOverflow 取得成功之后，我也对为我的一个网站实施成就系统非常感兴趣 - 所以我自己一直在思考这个问题。

我目前正在尝试评估拥有一个轻量级（在处理能力方面）例程的价值，我可以运行该例程以响应特定的用户操作（投票、新答案等），这可以保持大多数徽章- 最新的网站。

这将得到一个更重量级的例程的支持，该例程可以从头开始重新计算每个徽章。这可以从服务（或至少是模拟服务）定期运行，以确保没有遗漏任何东西 - 也可以响应徽章规则的变化。

我想这个答案的很大一部分将取决于您作为徽章奖励所依据的数据。StackOverflow 徽章似乎基于数据（答案、问题、投票等）和事件（编辑、重新标记等）。所以 - 徽章算法大概必须询问某种审计日志或“操作”日志。