Public interface EmployeeDAO{
Public void saveEmp(Employee emp);
}
public interface EmployeeService {
public void saveEmp(Employee emp);
}
@Repository("articleDao")
public class EmployeeDaoImpl implements EmployeeDao{
@Autowired
private SessionFactory sessionFactory;
@Override
public void saveEmployee(Employee emp) {
sessionFactory.getCurrentSession().saveOrUpdate(emp);
}
@Service("employeeService")
@Transactional(propagation = Propagation.SUPPORTS, readOnly = true)
public class ArticleServiceImpl implements ArticleService {
@Autowired
private EmployeeDao empDao;
@Transactional(propagation = Propagation.REQUIRED, readOnly = false)
public void saveEmployee(Employee emp) {
empDao.saveEmployee(emp);
}
}
Geeta Puttappanavar wrote:
1. Here EmployeeDAO, EmployeeService are same, then why to create to 2 interfaces?
Geeta Puttappanavar wrote:
2. Why to use @Transactional annotation (I know by using it we can work with Hibernate, JPA etc) but we can create other DaoImpl classes by using JDBC/Hibernate/JPA & let serviceImpl to call them. Here serviceImpl class simple calls the saveEmployee() method of DaoImpl. Then what s the advantage of using @Transactional?
Geeta Puttappanavar wrote:
3. In some forum I read that I need to write business logic in service class. What kind of business logic to write?
Geeta Puttappanavar wrote:
4. What s the difference between @Service & @Repository?
Bill Gorder wrote:
Geeta Puttappanavar wrote:
1. Here EmployeeDAO, EmployeeService are same, then why to create to 2 interfaces?
Some believe that there should always be a service layer and a repository layer. I come from the camp that if there is no service logic to be done then it basically becomes what I call a pass-through service to the Repository. In this case I would not bother with the service layer as it does not add any value.
Geeta Puttappanavar wrote:
2. Why to use @Transactional annotation (I know by using it we can work with Hibernate, JPA etc) but we can create other DaoImpl classes by using JDBC/Hibernate/JPA & let serviceImpl to call them. Here serviceImpl class simple calls the saveEmployee() method of DaoImpl. Then what s the advantage of using @Transactional?
@Transactional is just a declarative way to declare a transaction. Often times it is used in the service layer but if all you are doing is saving an object with no other business logic, there is no reason why the @Transactional could not live on the save method in the repository and just be called directly. However if there is service logic it makes sense for this to live in the service layer. Imagine you have a service with something like this.
In this case myReposiory.save and myRepository.update may or may not be annotated with @Transactional but in this case I want both save and update (an maybe some other stuff) to happen in a single transaction and roll all of it back if it fails. My service layer would worry about service stuff and delegate to the repository for making the queries.
Geeta Puttappanavar wrote:
3. In some forum I read that I need to write business logic in service class. What kind of business logic to write?
Depends on the application. There maybe lots of stuff going on or it may be as simple as grouping repository operations together, potentially wrapping them in a single atomic transaction.
Geeta Puttappanavar wrote:
4. What s the difference between @Service & @Repository?
These are Spring stereotype annotations. One thing they offer is for beans to automatically be created when they are detected with a component scan. The @Repository annotation add Springs DataAccessException translation so you no longer need to deal with the messy SQLException. @Service will possibly add more Spring features in the future but beyond what I have stated it is also useful for AOP and defining pointcuts.
Wink, wink, nudge, nudge, say no more, it's a tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
|