Q:

Is DAO a good practice in Spring JPA?

I'm learning Spring from a tutorial in Udemy, but the author uses Spring Boot 1.5.6 and I'm a little unsure about what he's doing. In a JPA example, he created a Client entity (Serializable) and then a ClientDAO interface plus its implementation. The implementation looks like this:
@Repository
public class ClientDaoImpl implements IClientDao {
    @PersistenceContext
    private EntityManager em;

    @Transactional(readOnly=true)
    @Override
    public List<Client> findAll() {
        return em.createQuery("from Client").getResultList();
    }
}

Is it a good practice to do that? I've watched a video before where the author used CrudRepository and made a service without implementing anything, let alone using this sort of SQL. Is this because it's an outdated version of Spring Boot or is this a good approach? This looks a lot like old JavaEE instead of Spring 5. Should I ignore that and do it with a CrudRepository and services?
Thanks.

A:

It's always a good practice if you can implement the service with as little code as possible. So if we can create a DAO service by declaring only the interface, it's better and is recommended by the official documentation for spring DATA.
interface ClientDao extends CrudRepository<Cliente, Long> {
}

However, for the purpose of learning, it's better to practice with the old way to understand how it works.

A:

It's perfectly fine. The example that you showed simply doesn't use Spring Data - it uses Spring DAO + JPA integration. Which is fine. Spring Data is yet another abstraction over this. With ORMs the typical possibilities that you have are:

Pure Hibernate + Spring DAO
JPA + Spring DAO
JPA + Spring Data

Which one to use is often dictated by personal preferences and experience. E.g. I'm okay with using Spring Data but my personal choice is always Hibernate + Spring Dao. So it's not a question of good or bad practices. 
Your project needs also influence the choice - e.g. performance requirements may lead you to abandoning ORMs in favour of Spring JDBC and native SQL queries.
One important thing to note - you don't lose time by learning low-level approaches. So if you don't know whether learning JDBC or pure JPA is a waste of time - that's never the case. High-level API is always based on low-level API and you can't become expert in the former without learning the latter.

