假设您要开发一个系统，实体和域逻辑的可用性高度依赖于用户上下文。通过使各个存储库实例用户上下文感知来处理存储库中的用户上下文敏感性是否有意义？我正在考虑采用这种方法作为一种方式来消除对我的实体的依赖用户背景，但我不确定是否有任何陷阱，我可能不会意识到这个方向。我计划首先接近这个的方法是将UserContext参数添加到需要此上下文信息的存储库的构造函数中。另一个明显的选择是将用户上下文信息提供给我的存储库中的每个查询方法，但这可能意味着大多数方法都需要这样的参数，这反过来会大大增加每个方法调用的详细程度。
另外我想指出，我知道即使我要使存储库用户上下文意识到当服务或实体需要相同的用户上下文信息时，这不一定有助于确定行为等原因基于用户配置。我也对这些案例的其他解决方案感兴趣但是现在我试图一次解决一件事，所以我首先关注的是存储库。
任何建议都将不胜感激。
答案 0 :(得分：1)
我在这里感觉到一种设计气味:-)。他们到达域层时的事情应该几乎被翻译成域实体/属性，并且不应该依赖于上下文。我的意思是应该使用上下文来改变/代表实体的新状态。在这里，似乎将使用上下文来确定实体将如何持久化。我理解正确吗？
话虽如此，如果您对上下文的依赖更多地来自基础架构而非业务功能角度，那么拥有上下文敏感的存储库就是您提出的正确模型。
为此，你能考虑像Spring一样通过Hibernate Session传递usercontext吗？这样，您的Repository类的构造函数或方法将受到较少的污染。但是，它确实会降低代码的可读性。
希望有所帮助。