Estoy pensando si realmente necesito una capa de servicio.Capa de servicio en la aplicación java swing
Estoy usando spring + hibernate para una aplicación de columpio de escritorio y en este momento tengo capa de gui/swing-> capa de servicio-> capa de dao. Utilizo la primavera solo para el soporte @Transactional y para la inyección IOC
Las mejores prácticas dicen que tengo que escribir un servicio para usar mis daos y poner toda la administración de transacciones en el servicio.
Pero me estoy dando cuenta de que muy a menudo, la capa de servicio sólo se replica Dao métodos, así por ejemplo:
// a DAO example
@Repository
public class CustomerHibernateDAO extends BaseHibernateDAO implements CustomerDAO {
public List<Customer> findAllCustomerILikeName(String name){
return getSession()
.createCriteria(Customer.class)
.add(Restriction.ilike("name", name))
.list();
}
}
// Customer service to use this dao...
@Service
@Transactional
public class CustomerService {
@Autowired
CustomerDAO customerDAO;
// Why i can't call DAO instead the service?
public List<Customer> getAllCustomersByName(String name){
return customerDAO.findAllCustomerILikeName(name);
}
}
Este es un uso típico de la mina capa de servicio ... Hibernate es DB-agnóstico, la primavera es agnóstica de la tecnología: ¿entonces realmente la necesito?
¿Qué tal una única clase de servicio para gestionar todos los DAO? Creo que esto puede ser un buen compromiso, o ¿es una mala práctica?
Sé puso en @Transactional DAO es una mala manera, pero en este momento tengo que escribir los servicios sólo para poner en ella ... @Transactional
EDITAR
Más información Sobre mi aplicación
Mi aplicación es un software de gestión y gestión de registro de usuarios, productos, pedidos y otros similares. En la práctica, contiene una gran cantidad de lecturas entidad-> editar-> guardar entidad o crear-> editar-> guardar operaciones, y, gracias a Hibernate, estas operaciones son administradas por ONE dao la mayor parte del tiempo, debido a que hibernate con @manyto ... collection y cascade.save_update permiten guardar dos o más entidades en la misma operación de persistir.
Así, por ejemplo, en mis artículos JFrame donde puedo insertar, modificar o crear un elemento (un producto para vender) hay:
public ItemFrame(){
// the constructor
itemService=springAppContext.getBeans(ItemService.class);
}
public boolean validateForm(){
// test if the gui is correctly filled by user
}
public boolean save(){
// create an Item entity taking value from swing gui(JTextField etc)
Item item=new Item();
item.setName(nameTextField.getText());
item.setEtc...
// ItemService ' save method is a wrap around itemDao.save(item)...
itemService.save(item);
}
private void saveItemActionPerformed(ActionEvent evt){
// When i press SAVE button
if(validateForm()){
save();
}
}
Esto es lo que tengo en la mayoría de los casos, así que creo que caí en anémico dominio antipatrón ...
Gracias.
en mi opinión lo está haciendo correctly.Services debería estar allí por Wil entity.It Mantengo un patrón estándar + si hay cambios en DB, solo estará construyendo la capa DAO, + 1 por cierto –
Si hay cambios en DB y no uso los servicios, ¿cuál es el problema? Voy a reconstruir mi DAO y todo está bien ... ¿o no? – blow
Me estoy saliendo un poco del tema aquí, pero ¿cuál es el motivo para obtener el frijol del contenedor usted mismo en el constructor de ItemFrame? No puedo ver ningún beneficio de este enfoque sobre obtener el frijol inyectado por el contenedor. – prasopes