没有.
Hibernate实体由Hibernate ORM框架管理,当您通过get()或load()访问它们时,它们(及其代理)由hibernate创建.它们具有与Spring bean完全不同(且复杂)的生命周期(它们可以被附加/分离/代理/等待删除)
Spring存储库是单例,由Spring框架管理.通常,只要容器实例存在,它们就存在.可以打开和关闭新的Hibernate会话,使用新的用户会话然后过期,但是仍然会有相同的存储库单例实例.
有关可能的hibernate对象状态,请参阅http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-overview.
至于存储库实例 - 通常它们是无状态的,因为它们是服务.
RE:they more or less imply the same.不,他们不一样.有一个老笑话
更换灯泡需要多少C++程序员?你仍然在程序上思考.正确设计的灯泡对象将继承通用灯泡类的更改方法,因此您所要做的就是发送灯泡更改消息.
但优秀的OOP程序员并不这么认为,根据单一责任原则,对象应该有一个改变的理由.存储库与基础结构一起使用,与业务规则无关.基础结构可能会发生变化(例如,您可能需要将对象存储在XML而不是RDBMS中),但这不应影响封装业务对象状态的类.
你可以通过从实体类到抽象存储库接口的引用来缓解这个问题(实现一个臭名昭着的Active Record模式 - 它就像从灯泡引用一些抽象的灯泡插座,这似乎不是一个好的解决方案,因为灯泡插座和灯泡有不同的生命周期).
这就是高凝聚力原理开始发挥作用的地方,根据这一点,它对于一个对象来说是不合逻辑的,它的作用是反映模型的抽象,执行一些完全无关的事情,如持久性或通过网络传输.这很奇怪,当Student班级都会有print(),saveToXml()或transmitByHttp()方法.
它们并不意味着完全相同.
@实体
@Entity代表业务领域中的"事物".它可以是任何东西 - 顾客,大象,产品...它将具有将持久存储到数据库的属性以及与这些属性相关的方法(至少它应该,除非它是一个贫血的实体,但这是一个反模式......后来,当你对这个属性感到满意时基础知识检查Spring的@Configurable注释 - 这允许您为您的实体提供协作者).
@Repository
另一方面,@ Repository提供了用于检索和存储这些实体的接口.
有一些框架,特别是在其他语言中,将持久性和实体属性组合在同一个对象上,但这在Java/Hibernate/Spring中并不常见.
| 归档时间: |
|
| 查看次数: |
1696 次 |
| 最近记录: |