相关疑难解决方法(0)

当在数据库中用作主键时,有人曾测量过Sequential Guid与Standard Guid的性能吗？

对于我的项目,这是一个潜在的大型网站,我选择将命令界面与查询界面分开.因此,提交命令是单向操作,不会返回结果.这意味着客户端必须提供密钥,例如:

service.SubmitCommand(new AddUserCommand() { UserId = key, ... });

显然我不能使用int作为主键,所以Guid是一个合乎逻辑的选择 - 除了我到处读到它对性能的影响,这让我感到害怕:)

但后来我也读到了关于COMB Guids,以及它们如何提供Guid的优势,同时仍然具有良好的性能.我还在这里找到了一个实现:Linq-to-Sql中的顺序GUID？.

所以在我做出这个重要决定之前:有人有这方面的经验吗？

非常感谢!

路德

由于上一篇文章(架构:简单的CQS),我一直在思考如何构建一个足够灵活的简单系统,以便以后扩展.

换句话说:我现在不认为需要一个完整的CQRS,但是如果需要的话,我希望以后能够很容易地发展它.

所以我在考虑将命令与查询分开,但两者都基于相同的数据库.

查询部分很简单:基于视图的WCF数据服务,可以轻松查询数据.没什么特别的.

命令部分更难,这里有一个想法:命令当然是以异步方式执行的,因此它们不会返回结果.但是,我的ASP.NET MVC站点的控制器通常需要来自命令的反馈(例如,如果成员的注册成功与否).因此,如果控制器发送命令,它还会生成与命令属性一起传递的事务ID(guid).命令服务接收此命令,将其放入数据库中具有状态'processing'的事务表中,并执行(使用DDD原则).执行后,事务表将更新,以便状态变为"已完成"或"失败",以及其他更详细的信息,如生成的主键.

同时,该站点使用QueryService来轮询此事务的状态,直到它收到"已完成"或"失败",然后它可以根据此结果继续工作.如果轮询事务表并且结果为"已完成"或"失败",则删除该条目.

副作用是我不需要guid作为我的实体的键,这对性能和大小来说是一件好事.

在大多数情况下,可能不需要这种轮询机制,但如果需要则可以.接口的设计考虑了CQS,因此对未来开放.

你认为这种方法有什么缺陷吗？其他想法或建议？

谢谢!

路德