如果你要构建一个类似于SO的徽章系统,你会直接将逻辑/业务层放在数据库中(通过存储过程,预定的sql作业)还是将它放在服务器端？
从我能想到的,你必须:
列出与当前用户操作相关的徽章
检查用户是否已经拥有徽章
为用户插入徽章
潜在的选择
调用存储过程等的Web应用程序中的业务逻辑
仅存储过程
每隔x分钟运行一次的SQL Server作业
每隔x分钟运行一次的Windows服务
是否需要这些组合？我认为,因为一些徽章是基于给定问题的里程碑,也许批量工作更好？
更新
您可以修改徽章系统,然后为每个人重新运行整个徽章链接的系统会更好.也就是说你改变了一些徽章的逻辑,现在你必须将它重新应用到所有的问题/答案/投票/等.
有趣的问题要解决!!
我建议将所有业务逻辑放在业务层中.我推荐这个有几个原因:
将业务逻辑保持在一种语言/位置
可伸缩性 - 您可以对数据进行分区,实现不同的缓存机制等.
关注点 - 让你的数据库做它最擅长的事情......存储数据,让你的编程语言决定数据.
我会把它放在业务层,毕竟这是我们正在讨论的业务逻辑.存储过程当然可以用来取回适当的数据,但我不是仅仅在数据库中实现决策逻辑的粉丝.如果不是因为在以后重新访问代码时变得越来越难以跟踪正在发生的事情.
京公网安备 11010802040832号 | 京ICP备19059560号-6 