服务和DAO总是实现接口

在我见过的所有MVC项目中，“服务”和“DAO”类总是实现自己的接口。 但几乎所有的时候，我都没有看到过这种界面有用的情况。

在这些情况下是否有任何理由使用接口？ 在“服务”和“DAO”类中不使用接口可能会导致什么结果？ 我无法想象任何后果。

---

有很多赞成界面的观点，请参阅Google。

我可以添加其他人提到的点：

想象一下，你将你的DAO实现从Hibernate改为iBatis。 依赖于接口而不是实现对于服务层来说是一个很大的帮助。

如果您使用AOP或代理使用JDK动态代理，那么您的类必须实现接口。 CGLIB并非如此。

在服务层中，如果您想将您的方法发布给其他客户端进行调用，那么给他们“作为契约的接口”会更有意义，而不是实现。

如果您想要将daemon.jar中的services.jar分开，那么在daos.jar更改的情况下，在daos上创建接口可以将services.jar从重新编译中保存。

总之，有接口就好！

---

Spring是一个控制反转容器。 这在某种意义上意味着您使用的类的实现不在应用程序上，而在于其配置。 如果你有一个需要UserRepository来存储User实例的类，它会是这样的

class UserService {
    @Autowired
    private UserRepository userRepository;
}

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

你会为它声明一个bean

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

注意这个bean是UserRepositoryHibernateImpl ，它将实现UserRepository 。

在世界的未来某个时候，Hibernate项目将不再受支持，并且您确实需要一个仅在Mybatis上可用的功能，因此您需要更改实现。 由于您的UserService类正在使用通过接口类型声明的UserRepository ，因此只有该接口上可见的方法对该类可见。 因此，更改userRepository的实际多态类型不会影响客户端代码的其余部分。 所有你需要改变（不包括创建新的课程）是

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

你的应用程序仍然有效。

---

基于接口的实现有助于在测试套件中模拟它们。 在我们的项目中，在测试服务层时，我们模拟DAO并提供硬编码数据，而不是真正连接到数据库。 同样的理由也适用于服务层。

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

上一篇: Service and DAO always implement interfaces

下一篇: task data structure in linux kernel module