DDD 存储库可以了解用户上下文吗？
假设您要开发一个系统，其实体和域逻辑的可用性高度依赖于用户上下文。通过使单个存储库实例用户上下文感知来处理存储库中的用户上下文敏感性是否有意义？我正在考虑采用这种方法，作为一种将用户上下文的依赖从我的实体中拉出来的方法，但我不确定在这个方向上是否存在我可能没有意识到的陷阱。我计划首先解决这个问题的方法是将 UserContext 参数添加到需要此上下文信息的存储库的构造函数中。另一个明显的选择是将用户上下文信息提供给我的存储库中的每个查询方法，但这可能意味着所有方法中的大多数都需要这样的参数，这反过来会大大增加每个方法调用的冗长性。
另外我想指出的是，我知道即使我要让存储库了解用户上下文，当服务或实体出于基于用户确定行为等原因需要相同的用户上下文信息时，这也不一定能直接提供帮助配置。我也对这些情况的其他解决方案感兴趣，但现在我试图一次解决一件事，所以我首先关注存储库。
任何建议将不胜感激。
Say you were to develop a system which availability of entities and domain logic is highly dependent on user context. Would it make sense to handle the user context sensitivity within repositories by making individual repository instances user context aware? I'm considering adopting this methodology as a way pulling the reliance on user context away from my Entities but I'm not sure whether there are any pitfalls that I may not be aware of with going this direction. The way I'm planning approaching this first is to add a UserContext parameter to the constructors of repositories that need this context information. The other obvious option would be to feed user context information into each query method in my repositories but this would likely mean that the majority of all methods would require such parameter which would in turn greatly increase the verbosity of each method call.
Also I would like to point out that I'm aware that even if I am to make repositories user context aware that this does not necessarily help directly when a service or entity needs that same user context information for reasons such as determining behavior based on user configuration. I'm interested in other solutions for these cases as well but for now I'm trying to tackle one thing at a time so I'm focusing on the repositories first.
Any suggestions would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在这里感受到了设计的味道:-)。当事物到达领域层时，它们几乎应该被转换为领域实体/属性，并且不应该依赖于上下文。我的意思是上下文应该用于改变/表示实体的新状态。在这里，上下文似乎更多地用于确定实体将如何被持久化。我的理解正确吗？
话虽如此，如果您对上下文的依赖更多地是从基础设施的角度而不是业务功能的角度来看，那么拥有上下文敏感的存储库就是您提出的正确模型。
为此，您是否可以考虑通过本地线程传递用户上下文，就像 Spring 对 Hibernate Session 所做的那样？这样你的 Repository 类的构造函数或方法就会减少污染。但是，它确实会稍微降低代码的可读性。
希望有帮助。
I sense a design smell here :-). Things by the time they reach domain layer should pretty much be translated into domain entities/attributes and should not have dependency on context. What I mean is the context should be used to change/represent the new state of entity. Here it more seems like that context is going to be used to determine how the entity is going to be persisted. Have I understood this correctly?
Having said that, if your dependency on context is more from an infrastructure perspective rather than business functionality perspective then having context sensitive Repositories is the right model you have come up with.
Towards that, could you consider passing usercontext through thread local like Spring does with Hibernate Session? This way your Repository class's constructors or methods would be less polluted. It, however, does reduce the readablility of your code a bit.
Hope that helps.