Service and DAO always implement interfaces

 

In all the MVC projects I've seen, "service" and "DAO" classes always implemented their own interfaces. But almost all the times, I haven't seen a situation in which having this interface has been useful.

Is there any reason to use interfaces in these cases? What may be the consequence of not using interfaces in "service" and "DAO" classes? I can't imagine any consequences.

There are lots of arguments in favour of interfaces, see Google.

I can added to the points other people mentioned:

  • Imagine you change your DAO implementations from Hibernate to iBatis. Dependency to interface rather than implementation would be a great help for the service layer.
  • If you use AOP or proxies using JDK dynamic proxies then your classes must implement interfaces. This is not the case for CGLIB.
  • In the service layer if you want to release your methods to other clients to call, giving them "interface as a contract" would make more sense rather than implementations.
  • If you ever want to separate services.jar from daos.jar then having interfaces on your daos would save the services.jar from recompile in case daos.jar changes.

    • In short, it is just good to have interfaces!

    Spring is an Inversion of Control container. This, in one sense, means that the implementation of classes you use doesn't fall on the application but on its configuration. If you have a class that needs a UserRepository to store User instances, it'd be something like 

    class UserService {
    @Autowired
    private UserRepository userRepository;
}

interface UserRepository {
    List<User> getUsers();
    User findUserBySIN(String SIN);
    List<User> getUsersInCountry(Long couyntryId);
}

    And you would have a bean declared for it 

    <bean class="com.myapp.UserRepositoryHibernateImpl">
   ...
</bean>

    Notice this bean is UserRepositoryHibernateImpl which would implement UserRepository .

    At some point in the future of the world, the Hibernate project stops being supported and you really need a feature that is only available on Mybatis so you need to change implementations. Because your UserService class is using a UserRepository declared with the interface type, only the methods visible on the interface are visible to the class. So changing the actual polymorphic type of userRepository doesn't affect the rest of the client code. All you need to change (excluding creating the new class) is 

    <bean class="com.myapp.future.UserRepositoryMyBatisImpl">
   ...
</bean>

    and your application still works.

    The interface-based implementation helps in mocking them in the test suite. In our project, while testing the service layer, we mock the DAOs and provide hard coded data instead of really connecting to the DB. The same argument applies to service layer as well.

    链接地址: http://www.djcxy.com/p/15412.html

    上一篇: 如何处理R中的C ++内部数据结构以允许保存/加载？

    下一篇: 服务和DAO总是实现接口