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