使用接口编写 DAO 类
我正在创建一个新的 Web 应用程序，它将使用一堆数据访问对象 (DAO) 类对数据进行 CRUD 操作。我知道当我有外部用户/应用程序使用我的 DAO 类时我应该编写 java 接口。但如果没有这样的需要，你认为我还应该写接口吗？我将使用 spring 将 DAO 类注入到 Spring 控制器（我正在使用 Spring MVC）类中。
I'm creating a new web application which will use a bunch of Data Access Object(DAO) classes for doing CRUD operations on the data. I know I should write java interfaces when I have external users/applications using my DAO classes. But if there is no such need do you think I should still write the interfaces? I'll be injecting DAO classes in to the Spring Controller(I'm using Spring MVC) classes using spring.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
注意：您应该始终尝试将接口与实现分开。这将使您可以使用此 DAO 层更好地控制其他层。
但是，正如您所知，接口为您提供了更多抽象，并使代码
更灵活、更能适应变化，因为您可以使用不同的
无需更改客户端即可实现同一接口。
不过，如果您认为您的代码不会改变，或者（特别是）如果您
认为你的抽象足够好，你不一定必须使用接口
换句话说：接口很好，但在为接口创建接口之前
每个班级都思考
NOTE THAT : You should always try to separating the Interface from the Implementation. This will give you more control to the other layers, using this DAO layer.
But, As you know an interface gives you more abstraction, and makes the code
more flexible and resilient to changes, because you can use different
implementations of the same interface without changing its client.
Still, if you don't think your code will change, or (specially) if you
think your abstraction is good enough, you don't necessarily have to use interfaces
In other words: interfaces are good, but before making an interface for
every class think about it
是的，你应该。使用它们的类应该仅依赖于接口。这使您能够使用 DAO 的虚假实现轻松初始化客户端类，以便测试这些类等。如果您只使用具体的类，那么 DAO 的客户端将直接依赖于该单一（数据库访问）实现，并且很难测试。
使类仅依赖于它们所依赖的服务的接口的简便性是依赖注入的主要优势之一，如果不利用它，您将对自己和您的应用程序造成伤害。
Yes, you should. Your classes that use them should rely on the interfaces only. This enables you to easily initialize the client classes with fake implementations of your DAOs in order to test those classes, among other things. If you just use a concrete class, then the clients of your DAOs will depend directly on that single (database accessing) implementation and be very difficult to test.
The ease of making classes rely only on interfaces for services they depend on is one of the main strengths of dependency injection and you'd be doing yourself and your application a disservice by not taking advantage of it.
您应该为 DAO（存储库？）编写接口的最大原因是，您可以轻松构建模拟（或使用模拟框架）来对依赖于 DAO 的任何内容进行单元测试。
即使您不进行单元测试，遵循 DIP 仍然是一个很好的设计
实践，在任何现代 IDE 中“右键单击=>提取界面”到底需要多长时间？
The biggest reason you should write interfaces for your DAO's (Repositories?) is so that you can easily build mocks (or use a mocking framework) to unit test anything which has a dependency ON the DAO.
Even if you're not doing unit testing, it is still a good design practice to follow DIP
Besides, how long does it really take to "right click=>Extract interface" inside of any modern IDE?
我不同意颜色混合。基本上我的观点是：任何由 spring 注入的东西都应该由接口支持（和引用）。
I disagree with Colour Blend. Basically my opinion is: anything that gets injected by spring should be backed (and referenced) by an interface.
为外部客户端设计 API 时的常见方法是创建接口，而不是类。
这样，客户端将只知道应在接口 javadoc 中明确说明的 API 契约，并且不会依赖于您选择的实现细节。
另外，您将能够通过提供 API 的模拟实现来在 JUnit 中测试 API 的客户端，如果您不使用接口，这将变得更加困难。
Common approach when designing API for external clients is to create interfaces, not classes.
This way client will know only about contract of API which should be explicitly stated in interface javadocs and there will be no dependency on implementation details you choose.
Plus, you will be able to test clients of your API in JUnit, by providing mock implementations of your API, which would be harder if you not using interfaces.
我认为你不应该。你只会浪费你的时间。仅在必要时创建它们。
I don't think you should. You'll just burn up your time. Create them only if it is necessary.