假设您要开发一个系统,实体和域逻辑的可用性高度依赖于用户上下文.通过使个人资料库实例用户上下文感知来处理存储库中的用户上下文敏感度是否有意义？我正在考虑采用这种方法作为一种将用户环境依赖于远离实体的方式,但我不确定是否有任何陷阱,我可能没有意识到这一方向.我计划接近的方法是将UserContext参数添加到需要此上下文信息的存储库的构造函数中.另一个明显的选择是将用户上下文信息提供给我的存储库中的每个查询方法,但这可能意味着所有方法中的大多数都将需要这样的参数,这将大大增加每个方法调用的详细程度.
此外,我想指出,我知道,即使我要使存储库用户上下文感知,这不一定有助于直接在服务或实体需要相同的用户上下文信息时,例如基于用户确定行为组态.我对这些案例的其他解决方案感兴趣,但是现在我正在尝试一次处理一件事情,所以我首先专注于存储库.
任何建议,将不胜感激.
我感觉到这里的设计气味:-).当他们到达域层的时候,事情应该几乎被翻译成域实体/属性,不应该依赖上下文.我的意思是上下文应该用来改变/表示新的实体状态.在这里,更多的是,这个上下文将被用来确定实体将如何被持久化.我明白了吗？
话虽如此,如果您从基础架构角度而不是业务功能角度来看,对上下文的依赖性更多,那么具有上下文敏感的存储库就是您提出的正确的模型.
为此,您是否可以考虑通过线程本地传递usercontext,如Spring与Hibernate Session？这样,您的Repository类的构造函数或方法将被更少的污染.但是,它确实会降低您的代码的可读性.
希望有帮助.
原文地址：https://www.jb51.cc/javaschema/281908.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
