问一些dao层的设计问题
我现在的做法是，没有用接口，所有的方法都是静态的，add update delete等等，在方法里开始事务，更新 并提交事务，例如

Java code

    public static void addSupplier(Supplier supplier){
        Session session = HibernateUtil.getSessionFactory().getCurrentSession();
        session.beginTransaction();
        session.save(supplier);
        session.getTransaction().commit();
    }

这样在业务逻辑里封装好后直接调用静态方法就完成了数据库操作。
但是现在发现一个问题，
就是事务，
每个方法都是单独的事务所以在一些操作中会很麻烦（比如添加物料入库单操作和更新库存操作）
现在的解决方法是把方法里面的session.getTransaction().commit();去掉在单独写一个提交事务的函数，在业务逻辑里增加提交事务的代码。

问题：
1.这种设计存在哪些问题？
2.有没有更好的或者是通用的解决方法？
3.看别人的代码里面有涉及到接口的，这是怎么回事？

------解决方案--------------------
分别定义事务开启和关闭函数,开启事务前获得SESSION,在调用关闭事务前执行所有的须在同一个事务完成的操作,完成执行后再调用事务关闭函数(传入this.transaction),这样做或许能达到要求(这样编写代码会让你明白执行的过程).也可以用spring和hibernate结合使用,由spring容器来管理事务的起止.
------解决方案--------------------
这种方法实不可取。主要是编程思想上的问题。
楼主想法可能是想找到通用的方法实现CRUD操作，其实就是简单、朴素的想实现代码重用。但是dao并不是代码重用的产物，虽然她也有这个功能。我们首先要拨开云雾，认清dao本质——实现对象持久化（或者分割对象持久化过程），让我们有跟多精力去解决客观世界的实际问题。更多的信息可以看看贫血的模式

我是这样认识dao的，对于现实客观世界，建立OO模型。之后，总会涉及到OO模型中关于对象状态变更、保存、归类、统计等问题。所以不可避免的碰到对象持久化的问题，而dao就是实现对象持久化的一种方法。
------解决方案--------------------
楼主可以去看看 j2ee 设计模式之事务上下文模式，在《J2EE 设计模式》一书中有介绍。



http://www.oreilly.com.cn/book.php?bn=7-5083-3099-4
------解决方案--------------------
容器管理的事务还是程序管理的事务，是有区别的。
如果你需要把一系列operation作为一个事物，应该在business层控制而不是在dao层