Intento seguir un tutorial sobre Spring MVC. En el tutorial está la interfaz UserDao (se usa Spring Data JPA)
public interface UserDao extends JpaRepository<User, Long> { User findByUsername(String username); }También existe UserService y UserServiceImpl
public interface UserService { void save(User user); User findByUsername(String username); } @Service public class UserServiceImpl implements UserService { @Autowired private UserDao userDao; @Autowired private RoleDao roleDao; @Autowired private BCryptPasswordEncoder bCryptPasswordEncoder; @Override public void save(User user) { user.setPassword(bCryptPasswordEncoder.encode(user.getPassword())); Set<Role> roles = new HashSet<>(); roles.add(roleDao.getOne(1L)); user.setRoles(roles); userDao.save(user); } @Override public User findByUsername(String username) { return userDao.findByUsername(username); } }Leí que todas las operaciones CRUD deberían ir en la capa dao.
Tienes razón. userDao.save(user) : esto es CRUD. Pero establecer la contraseña y agregar los roles: es parte de la lógica comercial. La capa DAO no debe saber nada sobre la lógica empresarial. En este caso, la capa dao solo debe tomar al user preparado y guardarlo en db. Eso es todo.
¿Cuál es el propósito de findByUsername(String nombre de usuario) en UserServiceImpl
Por la misma razón, findByUsername (String username) está en el Servicio. Ahora no pasa nada y solo se llama a un método desde el DAO. Pero de repente será necesario agregar algo de lógica antes de llamar al método desde el DAO.
La mayoría de los tutoriales para principiantes en la red muestran los métodos de servicio como tontos y terminan simplemente delegando la operación de guardado a DAO llamando al método de guardado de DAO, como en su ejemplo del método save(). Pero en las aplicaciones del mundo real, al menos el 50% de las veces tendrá alguna lógica de negocios para escribir como
1) Validar que el usuario pueda realizar alguna acción. 2) Verifique una condición previa o posterior antes de la actualización de datos. 3) Asegúrese de que existan otros datos antes de guardar, etc.
Entonces, aunque el método Servicio puede parecer análogo al método DAO o Repositorio, siempre es útil seguir el flujo de trabajo Controlador->Servicio->DAO en lugar de Controlador->DAO para que agregar lógica comercial al Servicio sea útil en el futuro. Espero eso ayude.