servicestack ServiceStack:在没有AuthUser的情况下持久化自定义用户对象

我正在研究ServiceStack的授权功能，并希望使用Couchbase作为我的数据存储。我知道Couchbase没有IUserAuthRepository实现，所以我必须开发自己的，这不是问题

我遇到的问题是，如果我按原样存储内置的UserAuth对象，那么它将使用Id字段作为文档标识符。这是一个问题，因为我认为标识符应该是特定于对象类型的，否则需要一个单独的“bucket”来防止不同对象之间的id冲突。我真的不想有很多桶，除非我不得不这么做

我的首选是将文档id设置为对象的类型加上特定于对象的标识符

例如使用Id“UserAuth_1234”或使用用户名“UserAuth_MikeGoldsmith”

我尝试为不同的应用程序对象重复使用一个bucket的假设有效吗？还是应该考虑为每个对象类型/名称空间使用一个bucket

欢迎Couchbase和ServiceStack爱好者提供任何指导

谢谢

其他信息

好的，根据John的回答，我将假设我的对象类型的附加属性是有效的

我在Mythz建议的示例中找到了这个示例，它使用自定义属性扩展了

AuthUser

。但是，在我看来，

AuthUser

被持久化了两次，第一次是作为

AuthUser

，第二次是作为

User

对象（两次都使用

OrmLiteAuthRepository

）。我说得对吗

本质上，我想利用SS auth功能，但控制将保存到Couchbase中的POCO对象。如果这是可能的，有人能给出一些指导吗？如果是的话，我需要实现什么

我尝试实现了一个Couchbase版本的

IUserAuthRepository

，但是它使用了UseAuth具体类型，因此我无法使用自己的对象

我还尝试连接到

AuthUserSession

的

OnAuthenticated

方法，但此时

UserAuth

POCO将使用register

IUserAuthRepository

持久化

我很高兴使用

CredentialAuthProvider

，因为我只需要用户名/密码身份验证。以后可以添加更多内容

---

再次感谢

bucket与关系世界中的数据库大致相似，因此通常不应将它们映射到应用程序对象。我不熟悉ServiceStack的auth特性，但您建议使用有意义的前缀键似乎是合理的，并且是提供文档分类的常用方法

请记住，在Couchbase中，文档中没有被视为“id”或“key”字段的字段。用于存储文档的键在元数据中可用，但不是JSON文档本身的一部分。因此，如果您能够利用视图，那么您还可以存储具有type属性的文档，然后通过一些非id属性进行查询。换句话说，键值中的键不必是检索用户身份验证文档的方式

---

此外，还有一些开发人员使用键前缀作为一种为视图提供文档分类的方法，所以您认为上面的键模式也适用于此。我的首选项是类型属性，但这并不比您的建议更有效。

我遇到了ServiceStack用例示例，其中一个直接解决了我的问题

---

我能够覆盖

TryAuthenticate

方法，并使用我自己的用户存储库返回Couchbase。

到目前为止，每个数据库一个存储桶、每个设计一个对象、每个查询一个视图的想法似乎是正确的。（意外地过早点击enter键，无法编辑我的第一篇帖子，以下是我的评论）我已经创建了具有id和类型属性的模型；我用来保存文档的键是这两个键的组合，即“{type}{id}”。正如你所建议的，我认为这是一种标准模式，与CB啤酒测试的工作原理非常相似。我遇到的问题更多的是ServiceStack问题。我想使用一个自定义用户对象并持久化到CB，而不存储SS的AuthUser对象。感谢您对bucket/document分类法最佳实践的澄清。嘿，Mike，您可能希望将您的答案标记为已接受，以帮助在寻求帮助时遇到您问题的其他人。嗨，Dan-我确实尝试过，但也阻止了我在接下来的几个小时内回答自己的问题。时间一过，我就来，谢谢。