- 浏览: 257098 次
- 性别:
- 来自: 北京
-
最新评论
-
aguai0:
好东西
JDK1.6官方下载_JDK6官方下载 -
dl96200:
谢谢了,,重装系统。jdk没了、、谢谢了
JDK1.6官方下载_JDK6官方下载 -
85273898:
good 顶
JDK1.6官方下载_JDK6官方下载 -
yang_min:
谢谢分享,,正好帮助了我。。
JDK1.6官方下载_JDK6官方下载 -
gongsy:
eeeexcvsfdsdf
JDK1.6官方下载_JDK6官方下载
以下的文章转载自
[url]http://kevintse.iteye.com/blog/151090 [/url]
原文地址:[url]http://www.hibernate.org/328.html [/url]
这是一个来自CaveatEmptor实例应用,在JDK5.0下实现的DAO模式. 这个模式在Java Persistence With Hibernate里面也有讲到. 另外有两个链接,可能会对你有用, Sessions and transactions 和 Open Session in View.
这次的DAO例子是基于接口的.很多工具, 像Hibernate已经提供了数据库的便携访问,所以我们不是为持久层的轻便而设计接口. 然而, DAO接口在较为复杂的应用中更有意义, 当有几个持久化服务被封装到一个持久层的时候, 我想在很多情况下你应该直接使用Hibernate或者JPA, 而使用外加的DAO层最好的理由是为了实现更高的抽象化(例如:定义方法名getMaximumBid()而不是无数次地重复session.createQuery(...)).
DAO接口
每一个持久化实体我用一个接口, 另外还有一个定义了泛型CRUD(增,删,改,查)操作的顶层接口.
你已经可以看到这将是一个"面向状态",具有像makePersistent()和makeTransient()方法的数据访问API.而且,你必须提供一个类型和一个标识参数(这里指的是持久化对象的标识符-Object Identifier),对于大多数的持久化解决方案,标识符类型必须是Serializable的.
以下是提供了类型参数关于某一实体的DAO接口,它继承了泛型接口:
基本上我们把通用的CRUD操作和具体业务相关的数据访问操作都分开了.(暂且不用理上面接口中的常量,如果使用Annotation,他们将会很有用.)然而,即使对于具体某个实体你只需要这些通用的CRUD操作,你也应该为它单独写一个接口.即使这个接口是空的.在你的controller code(控制器/业务代码)中使用一个具体的DAO是很重要的.否则当你要为这个实体引入具体的数据访问操作的时候,你将面临重构的问题.
一个Hibernate的(泛型DAO)实现
任何一个"可管理状态"的持久化服务都可以实现上面的泛型接口.首先,我们用Hibernate来实现这些泛型CRUD
在这个实现里面有几个有趣的东西. 第一,很明显它需要一个Sesssion来支撑,并且为这个Session提供了Setter注入.也可以用构造方法注入.你怎么设置Session或者这个Session的作用域(Scope,在这里应该是指Session的生命周期,接下来将它翻译作"生命周期"),都跟具体的DAO实现无关.DAO不应该控制事务或者Session的生命周期.
我们需要禁止一些未检查转换(unchecked casts)编译时警告.因为Hibernate的接口是基于JDK1.4的.接下来是泛型CRUD操作的实现,很简单,最后一个方法(设计得)很好,它用了另一个JDK5.0的新特性-varargs(不定参数),它帮助我们在具体实体DAO里面创建Criteria查询.下面是一个继承了用Hibernate实现的泛型DAO的具体DAO例子:
下面是另外一个使用超类中具有不定参数的findByCriteria()方法的例子:
为DAO准备工厂
我们可以把一切都放到一个DAO工厂里面, 这个工厂不仅在DAO被创建的时候为其设置Session,还包含了一些嵌套类,用来实现只包含与业务无关的CRUD(CRUD-only)操作的DAO:
上面的Hibernate DAO的具体工厂继承了下面的抽象工厂, 这个抽象工厂也将是我们在应用代码中使用的接口:
注意,这个工厂例子对于主要用一种持久化服务实现的持久化层都是适用的,例如Hibernate或者EJB3.0 持久化.如果你要混合使用持久化API, 例如, Hibernate和纯JDBC, 上面的模式只要改一点点,记住你是可以在一个特定的Hibernate DAO(用Hibernate实现的DAO)里面调用session.connection()的.或者可以使用很多Hierbate3.1 支持的SQL操作以避免用纯JDBC.
最后, 就是控制/命令处理代码(controller/command handler code)中的数据访问的样子了(选择你自己喜欢的事务划分策略,DAO中的代码不用改变)
数据库事务,不管是JTA还是JDBC,都将在一个为每个execute()方法而启动的拦截器中被开始和提交, 参照Open Session in View模式.你可以使用AOP来实现这些操作或者使用任何一种可以被包装到一个方法调用的拦截器里面. 见Session handling with AOP.
准备用手动实现依赖注入的DAO
不用写工厂,你也可以实现这个例子.
这里的缺点就是把持久层的实现类暴露给调用者(例如:ItemDAOHibernate和UserDAOHibernate) .还有,构造方法注入可能更加合适.
用lookup准备(实例化)DAO
如果调用者在DAO被创建的时候没有提供一个Session,则可以调用HibernateUtil.getSessionFactory().getCurrentSession()作为一种折衷的做法.
现在控制器通过直接实例化使用这些无状态数据访问对象
这个非常简单的策略(策略模式的实现)的唯一不足就是把持久层的实现类再一次地暴露给调用者--控制器(例如:ItemDAOHibernate和UserDAOHibernate),如果需要,你也可以提供一个自定义Session.
所有的这些用于设置当前Session和创建DAO实例的方法(factories, manual injection, lookup)都有他们的优势和劣势.所以,使用你觉得最comfortable的一种.
DAO AS 受管理EJB3.0组件
把你的DAO超类改成无状态会话Bean的基类(现在你所有的具体DAO都变成无状态EJB了,他们都有一个业务接口了).这里只用了一个注解(Annotation),只要你乐意,你甚至可以把它移到一个XML部属描述符里面.然后你就可以使用依赖注入和获得由容器提供的"当前"持久化上下文.
然后你就可以把一个EntityManager的委托强制转换为一个Hibernate Session了.
只有在你把Hibernate作为持久化提供者的时候,这才会起作用.因为这个委托是Session API, 在 JBoss AS 里面你甚至可以直接获得一个已经被注入的Session,如果你使用不同的Java持久化提供者, 那么将依赖于EntityManager API而非Session. 现在把你的DAO绑定到控制器(这个控制器其实也是一个受管理组件):
以下是原文的部分跟帖
----------------------------------------------------------------------------
Granularity 10 Sep 2005, 05:14 anthony
Christian说:每个特定实体对应一个DAO接口,这样没有什么问题,但是可以考虑用包(package)
对于粒度(granularity)只有一句话说.对于基于100个持久化对象的项目来说,如果你的项目设计良好,每10-30个类你会用一个包.
用例应该是被每个包的根实体所驱动的(言下之意:定义每个用例都是基于每个包的根实体),所以你可以每个包都定义一个DAO接口.
例子:如果你有Order * -- 1 Client这样的对象关系,并且你要获得一个特定客户的所有订单?一个用例是只需要获得订单,另外一个需要获得订单和订单所属的客户.你会在ClientDAO还是OrderDAO里面编写这些操作呢?尽管你知道Client是作为根实体的最好选择(译者注:就是说即使你知道Client是作为根实体的最好选择,但是你还要想到底是在ClientDAO还是OrderDAO里面编码,因为到这DAO实现一步的时候你自己又有点迷糊了).
这个例子很简单,但是想一下对拥有4或6级对象图的复杂HQL查询,添加这些代码不会很容易,并且如果你有一个很大的开发团队,那将有很大可能会重复代码.
设计你的包的时候你需要很小心.
Transaction Management in DAOs 30 Oct 2006, 06:25 prashantbasawa
在DAO外面进行事务管理不是一个好的想法(做法).事务管理应该在DAO里面,我们可以用一个策略模式(Strategy Pattern)向DAO插入事务管理的行为.
如下定义一个接口:
现在你可以在DAO里面为这个事务策略(transaction strategy)定义一个实例变量,像这样:
从此我们可以把事务管理代码移到将会在DAO里面被使用的策略类(TransactionStrategy ).
在以后,如果你像换成JTA事务,你可以创建一个新的事务策略.
还有,这些策略可以被设置到用HibernateDaoFactory.instantiateDAO(Class clazz)实例化的DAO里面,同时我们也可以在里面设置Session,我们还可以从一个属性文件里面取得策略信息(Strategy info),然后基于属性文件里面的属性你可以创建策略并且把它设置到DAO里面.
注意:Strategy也可以通过它的构造方法接收一个session.
--接着这个叫做prashantbasawa人又在下面说:
请忽略我在主题下面写的"注意"
Keep it simple 31 Oct 2006, 00:25 christian
当然,DAO不应该包含程式化的事务划分,不管你用什么时候的什么模式去隐藏它.
DAO最多可以为一个特定的方法接收一个事务上下文.这个问题用元数据能表达等更好,如:EJB3.0 Annotation(注解).
Re: Transaction Management in DAOs 13 Nov 2006, 02:12 prashantbasawa
对于持久化你能有多少个操作?只有3个,插入,更新,删除,这些你都可以实现一个超类使得没有重复编码.DAO里面不同的操作只是你查询各张表的时候用了不同的方式.我觉得对于查询数据你没必要使用事务,因为查询对数据库没做修改.
Re: Transaction Management in DAOs 14 Nov 2006, 05:19 christian
胡说八道!你必须保证读数据的正常ACID(原子性,一致性,隔离性,持久性),特别是当你想重复读取的时候保证隔离性.不要再在那里嚷嚷,"我真的不知道什么是自动提交".
Transaction scope 14 May 2007, 05:42 Olivier Billard
事务不应该由DAO开启和关闭, 下面是一个真正可靠的idea:
-在那种情况下(前面的Client-Order例子)你不能在一个事务里面包含几个DAO调用(这时候CRUD不能保证多个实体的原子性),这一点限制确实挺大的.
-在一个JTA事务中,你不能控制事务的生命周期,你可以能"参与"这个事务.
我想这两点说得很清楚,不要在DAO里面调用事务的being/commit方法.
当然,可能还有更多的观点.
[url]http://kevintse.iteye.com/blog/151090 [/url]
原文地址:[url]http://www.hibernate.org/328.html [/url]
这是一个来自CaveatEmptor实例应用,在JDK5.0下实现的DAO模式. 这个模式在Java Persistence With Hibernate里面也有讲到. 另外有两个链接,可能会对你有用, Sessions and transactions 和 Open Session in View.
这次的DAO例子是基于接口的.很多工具, 像Hibernate已经提供了数据库的便携访问,所以我们不是为持久层的轻便而设计接口. 然而, DAO接口在较为复杂的应用中更有意义, 当有几个持久化服务被封装到一个持久层的时候, 我想在很多情况下你应该直接使用Hibernate或者JPA, 而使用外加的DAO层最好的理由是为了实现更高的抽象化(例如:定义方法名getMaximumBid()而不是无数次地重复session.createQuery(...)).
DAO接口
每一个持久化实体我用一个接口, 另外还有一个定义了泛型CRUD(增,删,改,查)操作的顶层接口.
public interface GenericDAO<T, ID extends Serializable> { T findById(ID id, boolean lock); List<T> findAll(); List<T> findByExample(T exampleInstance); T makePersistent(T entity); void makeTransient(T entity); }
你已经可以看到这将是一个"面向状态",具有像makePersistent()和makeTransient()方法的数据访问API.而且,你必须提供一个类型和一个标识参数(这里指的是持久化对象的标识符-Object Identifier),对于大多数的持久化解决方案,标识符类型必须是Serializable的.
以下是提供了类型参数关于某一实体的DAO接口,它继承了泛型接口:
public interface ItemDAO extends GenericDAO<Item, Long> { public static final String QUERY_MAXBID = "ItemDAO.QUERY_MAXBID"; public static final String QUERY_MINBID = "ItemDAO.QUERY_MINBID"; Bid getMaxBid(Long itemId); Bid getMinBid(Long itemId); }
基本上我们把通用的CRUD操作和具体业务相关的数据访问操作都分开了.(暂且不用理上面接口中的常量,如果使用Annotation,他们将会很有用.)然而,即使对于具体某个实体你只需要这些通用的CRUD操作,你也应该为它单独写一个接口.即使这个接口是空的.在你的controller code(控制器/业务代码)中使用一个具体的DAO是很重要的.否则当你要为这个实体引入具体的数据访问操作的时候,你将面临重构的问题.
一个Hibernate的(泛型DAO)实现
任何一个"可管理状态"的持久化服务都可以实现上面的泛型接口.首先,我们用Hibernate来实现这些泛型CRUD
public abstract class GenericHibernateDAO<T, ID extends Serializable> implements GenericDAO<T, ID> { private Class<T> persistentClass; private Session session; public GenericHibernateDAO() { this.persistentClass = (Class<T>) ((ParameterizedType) getClass() .getGenericSuperclass()).getActualTypeArguments()[0]; } @SuppressWarnings("unchecked") public void setSession(Session s) { this.session = s; } protected Session getSession() { if (session == null) throw new IllegalStateException("Session has not been set on DAO before usage"); return session; } public Class<T> getPersistentClass() { return persistentClass; } @SuppressWarnings("unchecked") public T findById(ID id, boolean lock) { T entity; if (lock) entity = (T) getSession().load(getPersistentClass(), id, LockMode.UPGRADE); else entity = (T) getSession().load(getPersistentClass(), id); return entity; } @SuppressWarnings("unchecked") public List<T> findAll() { return findByCriteria(); } @SuppressWarnings("unchecked") public List<T> findByExample(T exampleInstance, String[] excludeProperty) { Criteria crit = getSession().createCriteria(getPersistentClass()); Example example = Example.create(exampleInstance); for (String exclude : excludeProperty) { example.excludeProperty(exclude); } crit.add(example); return crit.list(); } @SuppressWarnings("unchecked") public T makePersistent(T entity) { getSession().saveOrUpdate(entity); return entity; } public void makeTransient(T entity) { getSession().delete(entity); } public void flush() { getSession().flush(); } public void clear() { getSession().clear(); } /** * Use this inside subclasses as a convenience method. */ @SuppressWarnings("unchecked") protected List<T> findByCriteria(Criterion... criterion) { Criteria crit = getSession().createCriteria(getPersistentClass()); for (Criterion c : criterion) { crit.add(c); } return crit.list(); } }
在这个实现里面有几个有趣的东西. 第一,很明显它需要一个Sesssion来支撑,并且为这个Session提供了Setter注入.也可以用构造方法注入.你怎么设置Session或者这个Session的作用域(Scope,在这里应该是指Session的生命周期,接下来将它翻译作"生命周期"),都跟具体的DAO实现无关.DAO不应该控制事务或者Session的生命周期.
我们需要禁止一些未检查转换(unchecked casts)编译时警告.因为Hibernate的接口是基于JDK1.4的.接下来是泛型CRUD操作的实现,很简单,最后一个方法(设计得)很好,它用了另一个JDK5.0的新特性-varargs(不定参数),它帮助我们在具体实体DAO里面创建Criteria查询.下面是一个继承了用Hibernate实现的泛型DAO的具体DAO例子:
public class ItemDAOHibernate extends GenericHibernateDAO<Item, Long> implements ItemDAO { public Bid getMaxBid(Long itemId) { Query q = getSession().getNamedQuery(ItemDAO.QUERY_MAXBID); q.setParameter("itemid", itemId); return (Bid) q.uniqueResult(); } public Bid getMinBid(Long itemId) { Query q = getSession().getNamedQuery(ItemDAO.QUERY_MINBID); q.setParameter("itemid", itemId); return (Bid) q.uniqueResult(); } }
下面是另外一个使用超类中具有不定参数的findByCriteria()方法的例子:
public class CategoryDAOHibernate extends GenericHibernateDAO<Category, Long> implements CategoryDAO { public Collection<Category> findAll(boolean onlyRootCategories) { if (onlyRootCategories) return findByCriteria( Expression.isNull("parent") ); else return findAll(); } }
为DAO准备工厂
我们可以把一切都放到一个DAO工厂里面, 这个工厂不仅在DAO被创建的时候为其设置Session,还包含了一些嵌套类,用来实现只包含与业务无关的CRUD(CRUD-only)操作的DAO:
public class HibernateDAOFactory extends DAOFactory { public ItemDAO getItemDAO() { return (ItemDAO)instantiateDAO(ItemDAOHibernate.class); } public CategoryDAO getCategoryDAO() { return (CategoryDAO)instantiateDAO(CategoryDAOHibernate.class); } public CommentDAO getCommentDAO() { return (CommentDAO)instantiateDAO(CommentDAOHibernate.class); } public ShipmentDAO getShipmentDAO() { return (ShipmentDAO)instantiateDAO(ShipmentDAOHibernate.class); } private GenericHibernateDAO instantiateDAO(Class daoClass) { try { GenericHibernateDAO dao = (GenericHibernateDAO)daoClass.newInstance(); dao.setSession(getCurrentSession()); return dao; } catch (Exception ex) { throw new RuntimeException("Can not instantiate DAO: " + daoClass, ex); } } // You could override this if you don't want HibernateUtil for lookup protected Session getCurrentSession() { return HibernateUtil.getSessionFactory().getCurrentSession(); } // Inline concrete DAO implementations with no business-related data access methods. // If we use public static nested classes, we can centralize all of them in one source file. public static class CommentDAOHibernate extends GenericHibernateDAO<Comment, Long> implements CommentDAO {} public static class ShipmentDAOHibernate extends GenericHibernateDAO<Shipment, Long> implements ShipmentDAO {} }
上面的Hibernate DAO的具体工厂继承了下面的抽象工厂, 这个抽象工厂也将是我们在应用代码中使用的接口:
public abstract class DAOFactory { /** * Creates a standalone DAOFactory that returns unmanaged DAO * beans for use in any environment Hibernate has been configured * for. Uses HibernateUtil/SessionFactory and Hibernate context * propagation (CurrentSessionContext), thread-bound or transaction-bound, * and transaction scoped. */ public static final Class HIBERNATE = org.hibernate.ce.auction.dao.hibernate.HibernateDAOFactory.class; /** * Factory method for instantiation of concrete factories. */ public static DAOFactory instance(Class factory) { try { return (DAOFactory)factory.newInstance(); } catch (Exception ex) { throw new RuntimeException("Couldn't create DAOFactory: " + factory); } } // Add your DAO interfaces here public abstract ItemDAO getItemDAO(); public abstract CategoryDAO getCategoryDAO(); public abstract CommentDAO getCommentDAO(); public abstract ShipmentDAO getShipmentDAO(); }
注意,这个工厂例子对于主要用一种持久化服务实现的持久化层都是适用的,例如Hibernate或者EJB3.0 持久化.如果你要混合使用持久化API, 例如, Hibernate和纯JDBC, 上面的模式只要改一点点,记住你是可以在一个特定的Hibernate DAO(用Hibernate实现的DAO)里面调用session.connection()的.或者可以使用很多Hierbate3.1 支持的SQL操作以避免用纯JDBC.
最后, 就是控制/命令处理代码(controller/command handler code)中的数据访问的样子了(选择你自己喜欢的事务划分策略,DAO中的代码不用改变)
// EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED) public void execute() { // JTA: UserTransaction utx = jndiContext.lookup("UserTransaction"); // JTA: utx.begin(); // Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction(); DAOFactory factory = DAOFactory.instance(DAOFactory.HIBERNATE); ItemDAO itemDAO = factory.getItemDAO(); UserDAO userDAO = factory.getUserDAO(); Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, true); newBid = item.placeBid(userDAO.findById(userId, false), bidAmount, currentMaxBid, currentMinBid); // JTA: utx.commit(); // Don't forget exception handling // Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling }
数据库事务,不管是JTA还是JDBC,都将在一个为每个execute()方法而启动的拦截器中被开始和提交, 参照Open Session in View模式.你可以使用AOP来实现这些操作或者使用任何一种可以被包装到一个方法调用的拦截器里面. 见Session handling with AOP.
准备用手动实现依赖注入的DAO
不用写工厂,你也可以实现这个例子.
// EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED) public void execute() { // JTA: UserTransaction utx = jndiContext.lookup("UserTransaction"); // JTA: utx.begin(); // Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction(); ItemDAOHibernate itemDAO = new ItemDAOHibernate(); itemDAO.setSession(HibernateUtil.getSessionFactory().getCurrentSession()); UserDAOHibernate userDAO = new UserDAOHibernate(); userDAO.setSession(HibernateUtil.getSessionFactory().getCurrentSession()); Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, true); newBid = item.placeBid(userDAO.findById(userId, false), bidAmount, currentMaxBid, currentMinBid); // JTA: utx.commit(); // Don't forget exception handling // Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling }
这里的缺点就是把持久层的实现类暴露给调用者(例如:ItemDAOHibernate和UserDAOHibernate) .还有,构造方法注入可能更加合适.
用lookup准备(实例化)DAO
如果调用者在DAO被创建的时候没有提供一个Session,则可以调用HibernateUtil.getSessionFactory().getCurrentSession()作为一种折衷的做法.
public abstract class GenericHibernateDAO<T, ID extends Serializable> implements GenericDAO<T, ID> { private Class<T> persistentClass; private Session session; public GenericHibernateDAO() { this.persistentClass = (Class<T>) ((ParameterizedType) getClass() .getGenericSuperclass()).getActualTypeArguments()[0]; } public void setSession(Session session) { this.session = session; } protected void getSession() { if (session == null) session = HibernateUtil.getSessionFactory().getCurrentSession(); return session; }
现在控制器通过直接实例化使用这些无状态数据访问对象
// EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED) public void execute() { // JTA: UserTransaction utx = jndiContext.lookup("UserTransaction"); // JTA: utx.begin(); // Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction(); ItemDAO itemDAO = new ItemDAOHibernate(); UserDAO userDAO = new UserDAOHibernate(); Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, true); newBid = item.placeBid(userDAO.findById(userId, false), bidAmount, currentMaxBid, currentMinBid); // JTA: utx.commit(); // Don't forget exception handling // Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling }
这个非常简单的策略(策略模式的实现)的唯一不足就是把持久层的实现类再一次地暴露给调用者--控制器(例如:ItemDAOHibernate和UserDAOHibernate),如果需要,你也可以提供一个自定义Session.
所有的这些用于设置当前Session和创建DAO实例的方法(factories, manual injection, lookup)都有他们的优势和劣势.所以,使用你觉得最comfortable的一种.
DAO AS 受管理EJB3.0组件
把你的DAO超类改成无状态会话Bean的基类(现在你所有的具体DAO都变成无状态EJB了,他们都有一个业务接口了).这里只用了一个注解(Annotation),只要你乐意,你甚至可以把它移到一个XML部属描述符里面.然后你就可以使用依赖注入和获得由容器提供的"当前"持久化上下文.
@Stateless public abstract class GenericHibernateDAO<T, ID extends Serializable> implements GenericDAO<T, ID> { private Class<T> persistentClass; @PersistenceContext private EntityManager em; public GenericHibernateDAO() { setSession( (Session)em.getDelegate() ); }
然后你就可以把一个EntityManager的委托强制转换为一个Hibernate Session了.
只有在你把Hibernate作为持久化提供者的时候,这才会起作用.因为这个委托是Session API, 在 JBoss AS 里面你甚至可以直接获得一个已经被注入的Session,如果你使用不同的Java持久化提供者, 那么将依赖于EntityManager API而非Session. 现在把你的DAO绑定到控制器(这个控制器其实也是一个受管理组件):
@Stateless public class ManageAuctionController implements ManageAuction { @EJB ItemDAO itemDAO; @EJB UserDAO userDAO; @TransactionAttribute(TransactionAttributeType.REQUIRED) // This is even the default public void execute() { Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, true); newBid = item.placeBid(userDAO.findById(userId, false), bidAmount, currentMaxBid, currentMinBid); } }
以下是原文的部分跟帖
----------------------------------------------------------------------------
Granularity 10 Sep 2005, 05:14 anthony
Christian说:每个特定实体对应一个DAO接口,这样没有什么问题,但是可以考虑用包(package)
对于粒度(granularity)只有一句话说.对于基于100个持久化对象的项目来说,如果你的项目设计良好,每10-30个类你会用一个包.
用例应该是被每个包的根实体所驱动的(言下之意:定义每个用例都是基于每个包的根实体),所以你可以每个包都定义一个DAO接口.
例子:如果你有Order * -- 1 Client这样的对象关系,并且你要获得一个特定客户的所有订单?一个用例是只需要获得订单,另外一个需要获得订单和订单所属的客户.你会在ClientDAO还是OrderDAO里面编写这些操作呢?尽管你知道Client是作为根实体的最好选择(译者注:就是说即使你知道Client是作为根实体的最好选择,但是你还要想到底是在ClientDAO还是OrderDAO里面编码,因为到这DAO实现一步的时候你自己又有点迷糊了).
这个例子很简单,但是想一下对拥有4或6级对象图的复杂HQL查询,添加这些代码不会很容易,并且如果你有一个很大的开发团队,那将有很大可能会重复代码.
设计你的包的时候你需要很小心.
Transaction Management in DAOs 30 Oct 2006, 06:25 prashantbasawa
在DAO外面进行事务管理不是一个好的想法(做法).事务管理应该在DAO里面,我们可以用一个策略模式(Strategy Pattern)向DAO插入事务管理的行为.
如下定义一个接口:
public interface TransactionStrategy { public void beginTransaction(); public void commit(); } 一个实现接口的具体类 Java代码 public class DefaultTransactionStrategy { public void beginTransaction(){ HibernateUtil.getSessionFactory().getCurrentSession() .beginTransaction(); } public void commit(){ HibernateUtil.getSessionFactory().getCurrentSession() .commit(); } }
现在你可以在DAO里面为这个事务策略(transaction strategy)定义一个实例变量,像这样:
public class xyzDAO{ private TransactionStrategy transaction = null; public xyzDAO(){ transaction = new DefaultTransactionStrategy(); } public void insert(Object obj){ transaction.beginTransaction(); // Do some work session.load(...); session.persist(...); transaction.commit(); } public void setTransactionStrategy(TransactionStrategy strategy){ transaction = strategy; } }
从此我们可以把事务管理代码移到将会在DAO里面被使用的策略类(TransactionStrategy ).
在以后,如果你像换成JTA事务,你可以创建一个新的事务策略.
还有,这些策略可以被设置到用HibernateDaoFactory.instantiateDAO(Class clazz)实例化的DAO里面,同时我们也可以在里面设置Session,我们还可以从一个属性文件里面取得策略信息(Strategy info),然后基于属性文件里面的属性你可以创建策略并且把它设置到DAO里面.
注意:Strategy也可以通过它的构造方法接收一个session.
--接着这个叫做prashantbasawa人又在下面说:
请忽略我在主题下面写的"注意"
Keep it simple 31 Oct 2006, 00:25 christian
当然,DAO不应该包含程式化的事务划分,不管你用什么时候的什么模式去隐藏它.
DAO最多可以为一个特定的方法接收一个事务上下文.这个问题用元数据能表达等更好,如:EJB3.0 Annotation(注解).
Re: Transaction Management in DAOs 13 Nov 2006, 02:12 prashantbasawa
对于持久化你能有多少个操作?只有3个,插入,更新,删除,这些你都可以实现一个超类使得没有重复编码.DAO里面不同的操作只是你查询各张表的时候用了不同的方式.我觉得对于查询数据你没必要使用事务,因为查询对数据库没做修改.
Re: Transaction Management in DAOs 14 Nov 2006, 05:19 christian
胡说八道!你必须保证读数据的正常ACID(原子性,一致性,隔离性,持久性),特别是当你想重复读取的时候保证隔离性.不要再在那里嚷嚷,"我真的不知道什么是自动提交".
Transaction scope 14 May 2007, 05:42 Olivier Billard
事务不应该由DAO开启和关闭, 下面是一个真正可靠的idea:
-在那种情况下(前面的Client-Order例子)你不能在一个事务里面包含几个DAO调用(这时候CRUD不能保证多个实体的原子性),这一点限制确实挺大的.
-在一个JTA事务中,你不能控制事务的生命周期,你可以能"参与"这个事务.
我想这两点说得很清楚,不要在DAO里面调用事务的being/commit方法.
当然,可能还有更多的观点.
相关推荐
chrome-headless-shell-win64-135.0.7004.0 (Canary).zip
建筑工地个人防护装备分割系统源码&数据集分享
车牌字符识别系统源码分享[一条龙教学YOLOV8标注好的数据集一键训练_70+全套改进创新点发刊_Web前端展示]
实时可调的DDS信号发生器设计:基于FPGA的Verilog编程,灵活控制波形与频率的调制系统,(可实时切波形并控制频率)DDS信号发生器设计。 FPGA设计,verilog设计,DDS信号发生器:基于调制方式灵活可控的信号发生器DDS。 可生成ASK调制波、FSK调制波、正弦波、矩形波、三角波、锯齿波等多种波形。 方案采用三个按键控制,可按键控制不同信号、不同频率输出。 按键1:控制切六种波形(ASK调制波,FSK调制波,正弦波,矩形波,三角波,锯齿波)。 按键2:每按下一次,频率增加1 10。 按键3:每按下一次,频率减小1 10。 频率相位可灵活调整。 ,核心关键词: 1. DDS信号发生器设计 2. FPGA设计 3. Verilog设计 4. 调制方式 5. 波形切换 6. 频率控制 7. 按键控制 8. 频率相位调整 用分号分隔的关键词结果为:DDS信号发生器设计;FPGA设计;Verilog设计;调制方式;波形切换;频率控制;按键控制;频率相位调整;,灵活控制的FPGA设计:基于DDS技术的信号发生器实现方案
一个windows上使用的搜索小工具
2024免费毕业设计成品,包括源码+数据库+往届论文资料 启动教程:https://www.bilibili.com/video/BV11ktveuE2d 讲解视频:https://www.bilibili.com/video/BV1YfkHYwEME 二次开发教程:https://www.bilibili.com/video/BV1Cw2rY1ErC
标题:基于放射虫和硅藻的温度重建揭示南大洋印度洋扇区表面及亚表面温度变化 内容: 一项最新的研究在南大洋印度洋扇区的四个沉积物核心中提出了五项新的温度记录。这项研究使用了名为SORAD的数据集作为训练集,应用Imbrie和Kipp方法对经过对数转换的数据进行分析,重建了基于放射虫的亚表面温度(subST)。此外,通过利用Crosta等人于2020年编制的包含249个样本的数据集,并采用现代类似种技术应用于33个硅藻分类单元的相对丰度,预测了基于硅藻的海表温度(SST)。 特别地,来自DCR-1PC(Crosta等人,2020年)和MD19-3580(本研究)的核心SST记录以及来自MD19-3575CQ和MD19-3580(本研究)的核心subST记录被重采样至每3千年一个间隔,以便从SST中减去subST在这两个核心站点的值(DCR-1PC/MD19-3575CQ和MD19-3580),从而重建表面与亚表面之间温度差(deltaT)的演变过程。本研究包括了这些重采样数据和deltaT记录,为理解该地区过去气候条件提供了重要线索。
人脸表情行为识别系统源码分享[一条龙教学YOLOV8标注好的数据集一键训练_70+全套改进创新点发刊_Web前端展示]
Zabbix 适用于各种规模的企业和组织,特别是那些需要监控复杂 IT 基础设施的用户。以下是一些使用 Zabbix 的优势: 开源免费:Zabbix 是开源软件,可以免费使用,且社区活跃,文档丰富。 高度可定制:用户可以根据需求自定义监控项、告警规则和报表。 跨平台支持:支持多种操作系统(Linux、Windows、Unix等)和数据库(MySQL、PostgreSQL、Oracle等)。 强大的社区支持:Zabbix 拥有庞大的用户社区,用户可以轻松找到解决方案和最佳实践。 企业级功能:支持高可用性、分布式监控和自动化运维,适合企业级应用。 该软件包使用rockylinux8、mysql、nginx。 软件使用:解压,createrepo创建本地yum仓库,创建仓库文件,可yum或dnf 下载,详细见:https://blog.csdn.net/m0_74744227/article/details/145389193
豆类苗叶检测系统源码分享[一条龙教学YOLOV8标注好的数据集一键训练_70+全套改进创新点发刊_Web前端展示]
魔众视频管理系统是由国内领先的技术团队开发商进行开发的,是搭建视频系统最佳选择的程序源码,支持多端同步浏览。 魔众视频管理系统,轻量级视频管理系统。 2022年08月19日魔众视频管理系统发布v4.1.0版本,增加了以下27个特性: ·[新功能] 文件上传切片最大2M,分片文件根据配置动态清除 ·[新功能] 图标库中新增cube图标 ·[新功能] UEditorPlus升级到2.3.0 ·[新功能] bodyProperties可为body标签增加属性 ·[新功能] 图标库新增 check-simple ·[新功能] Cookie库新增属性参数 ·[新功能] 后台管理员角色新增备注字段 ·[新功能] Grid编辑操作名称可自定义 ·[新功能] FileUtil新增文件大小精简格式化 ·[新功能] 登录界面全新改版大气美观 ·[新功能] Type类型数据新增导出JS配置文件 ·[新功能] 富文本组件新增 editor-ready 自定义事件 ·[新功能] Response新增停止执行抛出消息的方法 ·[新功能] Grid新增批量弹窗快捷操作方式 ·[新功能] Json组件增加高度可配
永磁同步电机Q15焦点:无传感自适应滑膜算法及SMO_C语言定点代码与仿真模型示例解析,永磁同步电机无传感自适应滑模 滑膜观测器(SMO)_示例C语言定点代码和仿真模型,Q15 foc pmsm 使用“自适应”滑模算法消除一阶滤波器 ,核心关键词:永磁同步电机; 无传感自适应滑模; 滑膜观测器(SMO); C语言定点代码; Q15; foc pmsm; 自适应滑模算法; 一阶滤波器。 关键词用分号分隔为:永磁同步电机; 无传感; 自适应滑模; 滑膜观测器(SMO); C语言定点代码; Q15; foc pmsm; 一阶滤波器。,"自适应滑模算法在永磁同步电机中的应用:Q15定点代码与仿真模型示例"
Python泰勒图实现多模型可视化对比:源码高逼格版展示与使用教程,Python高逼格泰勒图及源码~,多模型对比~可视化工具 ,Python; 泰勒图; 高逼格; 多模型对比; 可视化工具,Python泰勒图高逼格展示:多模型对比可视化工具源码
基于WOA-XGBoost的回归预测:以优化XGBoost树参数的改进算法研究(基于MATLAB代码,包括评价指标),基于鲸鱼算法优化极限梯度提升树的数据回归预测(WOA-XGBoost) 鲸鱼算法WOA优化极限梯度提升树XGBoost树的数量、树的深度和学习率 基于MATLAB环境 替自己的数据即可 代码注释清晰 适合学习 回归预测的评价指标包括平均绝对误差 均方误差 均方根误差 平均绝对百分比误差以及关联系数 ,WOA-XGBoost; 鲸鱼算法优化; 树的数量; 树的深度; 学习率优化; MATLAB环境; 代码注释清晰; 回归预测; 评价指标,基于WOA-XGBoost算法的数据回归预测模型
介绍: 在2025年,随着技术的不断进步和用户需求的多样化,社区平台的设计与功能也在不断演变。StarFree作为一款全新的唯美风格社区源码,凭借其独特的设计理念和强大的功能,迅速成为了开发者与用户关注的焦点。本文将为您详细介绍StarFree源码的特点、功能以及应用场景。 1. 唯美设计,极致视觉体验 StarFree源码以“唯美”为核心设计理念,采用了简约而不失优雅的UI设计。整体界面以柔和的色调为主,搭配流畅的动画效果,为用户带来极致的视觉享受。无论是社区主页、个人中心,还是帖子详情页,每一个细节都经过精心打磨,确保用户在浏览时感受到舒适与愉悦。 2. 模块化架构,灵活扩展 StarFree采用模块化架构设计,开发者可以根据需求自由组合或扩展功能模块。无论是社交互动、内容发布,还是用户管理,每个模块都独立且高效,便于二次开发与定制。这种设计不仅降低了开发难度,还提高了系统的可维护性。 3. 多端适配,无缝体验 StarFree源码支持多端适配,包括Web端、移动端(iOS/Android)以及小程序。无论用户通过哪种设备访问社区,都能获得一致且流畅的体验。源码内置响应式布局
open3d qt6demo示例
2024免费毕业设计成品,包括源码+数据库+往届论文资料 启动教程:https://www.bilibili.com/video/BV11ktveuE2d 讲解视频:https://www.bilibili.com/video/BV1YfkHYwEME 二次开发教程:https://www.bilibili.com/video/BV1Cw2rY1ErC
二维码与条形码检测系统源码分享[一条龙教学YOLOV8标注好的数据集一键训练_70+全套改进创新点发刊_Web前端展示]
内容: 该数据集由Moraitou-Apostolopoulou, M、Zervoudaki, S和Kapiris, K于2013年发布,提供了1994年9月和12月在爱琴海收集的翼足类(一种浮游软体动物)丰度数据。数据集包含了90个数据点,详细记录了这两个时间点翼足类的数量情况。此研究有助于了解气候变化对海洋生态系统中特定物种的影响。访问以下链接获取完整数据集: 请注意,直接点击上述链接将引导您至数据集的官方页面,而非直接下载页面。
1. 用户管理 用户注册与登录:支持志愿者(学生)、管理员(指导老师)等角色的注册与登录。 角色权限管理:根据不同角色分配相应的权限,如志愿者可以查看活动信息、报名,管理员可以管理活动及志愿者信息。 2. 志愿者信息管理 志愿者档案管理:记录志愿者的基本信息,包括姓名、学号、联系方式、专业等。 技能特长登记:志愿者可以添加自己的技能、特长,为活动匹配合适的志愿者。 3. 活动管理 活动信息发布:管理员可以创建、编辑和删除志愿者活动信息,包括活动名称、时间、地点、人数限制等。 活动查询与搜索:志愿者可以查看所有活动,支持按标签、时间等条件搜索活动信息。 4. 报名管理 在线报名:志愿者可在线报名参加活动,系统自动更新参与人员信息。 报名状态查询:志愿者可以查看自己报名的活动及其状态(已报名、待审核、已结束等)。 5. 反馈与评价 活动反馈:参与完活动后,志愿者可以填写反馈表,评价活动内容和组织。 统计分析:管理员可以对反馈进行统计分析,改进后续活动的安排。 6. 通知管理 消息推送:通过系统向志愿者发送活动提醒、重要通知等。 公告板:展示志愿者最新动态、活动报道等信息。 7. 系统管理