CQRS 中的新建/读取标志
我目前正在起草一个（主要是）基于 HTML 的协作套件的概念，我计划使用 CQRS 来实现该套件。该软件将包含可以发送给用户的消息（显然可以是已读或未读）以及其他元素，如果它们是在上次用户登录后创建的，则应标记为“新”。 几乎不是什么新鲜事，但我不太确定如何使用 CQRS 正确实现这一点。据我了解，任何类型的更改都应该无一例外地只能通过命令来实现。但是为正在访问的每个（新）元素创建命令似乎有点太多，更不用说开销了。 我不知道我是否需要它，但是在元素上实现上次访问时间戳的最佳方法是什么。基本上与上面的问题相同，不同之处在于每次访问元素时都会发生更改，而不仅仅是每个用户第一次访问。
CQRS 似乎是一个很棒的概念，但它确实需要更多的学习材料。等不及一本书出版了:)
问候
[编辑]没有人吗？没想到这个问题这么复杂。。
I am currently drafting a concept for a (mostly) HTML-based collaboration suite which I plan to implement using CQRS. This software will contain messages that can be sent to the user (which can either be read or unread, obviously) and other elements which shall be marked "new" if they were created after the last user login.
Hardly something new, but I am not quite sure how that would be correctly implemented using CQRS. As I understand it, Change of any kind should, without exception, only be possible via Commands. But creating commands for every single (new) element that is being accessed seems a bit too much, not to mention the overhead.
I don't know if I need it, but what would be the best way to implement a Last-Accessed Timestamp on elements. Basically the same problem like the above, with the difference that the change happens EVERY time the element is accessed, not only the first time for each user.
CQRS seems to be an awesome concept but it really needs more learning material. Can't wait till a book is released :)
Regards
[Edit] No one? Wouldn't have thought that this is such a complicated issue..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我假设您正在使用事件源，在这种情况下，一旦您允许查询服务/事件处理程序引发适当的事件，那么这将变得相当容易解决。
对于您的消息/元素；处理元素的特定创建事件时，添加到现有或创建其他事件处理程序，以存储到状态为新的消息读取模型 以及有关元素的适当信息。
作为用户登录的一部分，我不明白为什么您不能引发用户登录事件（来自安全/查询服务，具体取决于您实现身份验证的方式）来表明用户已登录。事件-handler 可以捕获此信息并将上次登录时间戳写入特定的用户上次登录读取模型。
此外，用户登录的事件处理程序需要将（该用户的）所有新消息更新为未读状态。鉴于我们在用户登录时更改消息的状态，您是否仍然需要存储上次登录时间戳？
对于您上次访问的时间戳，也许您可以在不同元素的查询完成时将其工作到您的查询服务中。使用元素 id/类型信息引发查询完成事件。
I assume you're using event-sourcing in which case once you allow your query-service/event-handlers to raise appropriate events then this becomes fairly easy to solve.
For your messages/elements; when handling the specific creation events of your elements either add to existing or create additional event-handlers, to store to a messages read-model with a status of new and appropriate information about the element.
As part of you're user login I don't see why you can't raise a user-logged-in event (from the security/query service depending on how your implementing authentication) to say the user has logged in. An event-handler could capture this and write the last-login timestamp to a specific user-last-login read-model.
In addition the user-logged-in event-handler would need to update all the new messages (for that user) to an unread status. Seeing as we're changing the status of the messages as the user logs in do you still need to store the last-login timestamp?
For your last-accessed timestamp, perhaps you could just work this into your query service as queries for your different elements complete. Raise a query-completed event with element id/type information.