标签: dao

在我之前的问题,DAO和服务层(JPA/Hibernate + Spring)之后,我决定在使用JPA/Hibernate,Spring和Wicket的应用程序中仅使用一个DAO作为我的数据层(至少在开始时).提出了使用通用CRUD方法,但我不太确定如何使用JPA实现它.你能给我一个例子或分享一个关于这个的链接吗？

我在一些文章中读到DAO对于hibernate并不是强制性的,它的实现是"依赖于",换句话说,我们可以在ORM与DAO模式之间进行选择.

好吧,我们假设我不想使用DAO模式,所以我只使用会话CRUD和hibernate提供的查询操作(我的ORM).

特别是对于"搜索"和"查找"查询来说,总是重写它们是不正确的,所以合理的想法就是把它们放到一个类中.

但是这个类是一个简单的DAO,没有DAO模式和DAOFactory的所有实现,只是DAO的轻量级实现.所以,重点是我们总是需要一个DAO,选择是重DAO实现还是轻量级DAO实现？

我说的是错的？

编辑 我的另一个问题是放置dao交互,例如我必须登录用户并写入登录日志(我知道无用的例子......)

所以在DAO模式中,我有所有泛型dao实现,DAOFactory,最后是UserHibernateDAO和LogHibernateDAO.登录操作是一种业务方法:

private void login(String username, String password){
    daoFactory.beginTransaction();
    UserDAO userDao=daoFactory.HIBERNATE.getUserDao();
    LogDAO logDao=daoFactory.HIBERNATE.getLogDao();
    if(userDao.checkAccount(username, password){
        User user=userDao.findByAccount(username, password);
        logDao.save(new Log("log-in", user);
    }
    daoFactory.commit();
}

这合理吗？我可以用这种方式使用dao吗？如果我想要处理异常,那么更好的地方就是业务逻辑？

EDIT2 让我们假设使用DAO模式,这样做的主要原因是能够在tecnhology(ORM-> JDBC等等)之间切换,一切都很好,但是我可以在哪里处理hibernate会话和事务？我不能把它放到DAO中,这是anty模式,我不能把它放到服务层,因为在hipohtetycal开关我必须删除所有这个交易(因为其他技术可能不会使用它们).

我发现JPA,或类似的,不鼓励DAO模式.我不知道,但我觉得这样,尤其是服务器管理的JTA经理.

在使用DAO模式进行了充分的实践之后,我开始围绕该模式设计基于JPA的应用程序.但它不适合,IMO.我倾向于失去JPA和所有的功能.

好吧,假设您使用悲观锁定触发查询,并从DAO方法返回了一个entites列表.返回后,事务结束并且锁定消失(服务器管理的JTA管理器的情况).所以,没有意义,松散地说.但是有一些有效的案例.

另一个例子更为微不足道.假设您触发查询以获取某个实体,该实体具有延迟加载与其他实体的一对多关联.返回DAO方法后,事务结束.延迟加载将不再起作用,你只是得到null或什么.为了应对这种情况,我们热切地手动加载它.我们做的事情就像a.getBList().size().

因此,IMO最好不要专门制作DAO,并且在您的业务bean中执行此操作,这样您就可以利用这些有用的功能.或者可以说ORM API可以被认为是DAO /数据层本身.所以,我们不需要另一个.

你们有什么想法呢？

注意:我没有说,DAO模式已经过时了.实际上,这取决于具体情况.

我知道工厂和抽象工厂方法,但我想用Java创建一个DAO工厂模式.

1. 我想知道它的重要性.
2. 它的用法

我查了一下这个链接,但我很难理解.

任何人都可以借助一个例子来解释它吗？

编辑:这是我理解的DAO模式的一个例子:

public interface UserDAO {
    public void insert(User user);
    public void update(User user);
    public void delete(int userId);
}

执行:

public class UserDAOImpl implements UserDAO {
    @Override
    public void delete(int userId) {
        // delete user from user table
    }

    @Override
    public User[] findAll() {
        // get a list of all users from user table
        return null;
    }

    @Override
    public User findByKey(int userId) {
        // get a user information if we supply unique userid …

我的web应用程序已经得到了很多服务表/实体,如payment_methods,tax_codes,province_codes,等.

每次我添加一个新实体,我都要写一个DAO.问题是,基本上,它们都是一样的,但唯一的区别是实体类本身.

我知道Hibernate工具可以自动为我生成代码,但我现在不能使用它们(不要问为什么)所以我在考虑使用Generic DAO.有很多关于这方面的文献,但我不能把它们放在一起,让它与Spring一起工作.

我认为这是关于泛型的,它将有四种基本方法:

• listAll
• saveOrUpdate
• deleteById
• getById

就这样.

题:

不重新发明车轮的最佳做法是什么？是不是有东西可以使用了呢？

是否可以使用Yii的ActiveRecord在一个查询中插入多行？或者这只能通过较低级别的DAO对象实现？

我正在开发一个Java桌面应用程序,但在为持久层选择技术方面存在一些困惑.

直到现在,我一直在使用JDBC进行数据库操作.现在,最近我学习了Hibernate和JPA,但我仍然是这些技术的新手.

现在我的问题是如何从我的Java桌面应用程序中使用以下内容？

• JPA

• 过冬

• JDBC

• DAO

• 你的任何其他建议......

我知道他们没有最好的选择,这完全取决于项目的复杂性和重新发现,所以下面是我项目的要求

1. 这不是一个复杂的应用程序.它只包含5个表(和5个实体)
2. 我不想让我的代码变得灵活,以便我以后可以轻松地更改数据库
3. 应用程序的大小应尽可能小,因为我必须通过互联网将其分发给我的客户.
4. 它必须可以自由地用于商业开发和分销.

==================================== EDITED ============= ==========================

根据以下答案,我想使用JPA,以防止自己编写特定于供应商的SQL代码.

但是我在Java Persistence API中提到的JPA中存在一些问题

我目前正在使用带有Spring插件和hibernate的Struts2开发一个Web应用程序,当我查看在线示例时,我看到了Service和DAO层的使用,现在我看到了Service和数据访问对象层的真正用途是什么？如果服务层只是调用DAO层的方法来执行CRUD操作.直接调用DAO图层方法是不明智的？

让我们说这个Dao和服务层的例子

PeopleService

  @Transactional
    public class PeopleService {

        private PeopleDao pDao;

        public PeopleDao getPDao() { return pDao; }

        public void setPDao(PeopleDao peopleDao) { this.pDao = peopleDao;   }

        public void createPerson(String name){
            pDao.createPerson(name);
        }

        public List<Person> getPeople(){
            return pDao.getPeople();
        }

    }

PeopleDao

public class PeopleDao {

    private SessionFactory sessionFactory;

    public void setSessionFactory(SessionFactory sessionFactory) {
        this.sessionFactory = sessionFactory;
    }

    public Session sess() {
        return sessionFactory.getCurrentSession();
    }

    public Person getPersonById(long id) {
        return (Person) sess().load(Person.class, id);
    }

    public void deletePersonById(long id) {
        sess().delete(getPersonById(id)); …

数据访问对象(DAO)是一种常见的设计模式,由Sun推荐.但最早的Java DAO示例直接与关系数据库进行交互 - 它们本质上是做对象关系映射(ORM).如今,我看到DAO在成熟的ORM框架之上,如JDO和Hibernate,我想知道这是不是一个好主意.

我正在使用JDO作为持久层开发Web服务,并且正在考虑是否引入DAO.我在处理包含其他对象映射的特定类时遇到了问题:

public class Book {
    // Book description in various languages, indexed by ISO language codes
    private Map<String,BookDescription> descriptions;
}

JDO足够聪明,可以将其映射到"BOOKS"和"BOOKDESCRIPTIONS"表之间的外键约束.它透明地加载BookDescription对象(我​​相信使用延迟加载),并在Book对象持久化时保留它们.

如果我要引入一个"数据访问层"并编写一个像BookDao这样的类,并将所有JDO代码封装在其中,那么这个JDO对子对象的透明加载不会绕过数据访问层吗？为了保持一致性,不应该通过一些BookDescriptionDao对象(或BookDao.loadDescription方法)加载和保存所有BookDescription对象吗？然而,以这种方式进行重构将使得模型的操作变得不必要地复杂化.

所以我的问题是,在业务层中直接调用JDO(或Hibernate,或者你想要的任何ORM)有什么问题？它的语法已经非常简洁,并且与数据存储区无关.如果有的话,将它封装在数据访问对象中有什么好处？

我正在尝试习惯JSF如何处理数据(来自弹簧背景)

我正在创建一个维护用户列表的简单示例,我有类似的东西

<h:dataTable value="#{userListController.userList}" var="u">
    <h:column>#{u.userId}</h:column>
    <h:column>#{u.userName}</h:column>
</h:dataTable>

然后"控制器"有类似的东西

@Named(value = "userListController")
@SessionScoped
public class UserListController {
    @EJB
    private UserListService userListService;

    private List<User> userList;

    public List<User> getUserList() {
        userList = userListService.getUsers();
        return userList;
    }
}

而"服务"(虽然看起来更像是DAO)有

public class UserListService {

    @PersistenceContext
    private EntityManager em;

    public List<User> getUsers() {
        Query query = em.createQuery("SELECT u from User as u");
        return query.getResultList();
    }
}

这是正确的做事方式吗？我的术语是对的吗？"服务"感觉更像是DAO？控制器感觉它正在做一些服务工作.