【问题标题】:Use of Interfaces on a service layer在服务层上使用接口
【发布时间】:2015-04-25 22:06:40
【问题描述】:

在我们的项目架构中,我们使用经典的 MVC 模式,包括经典的服务层(打开事务并调用 DAO 层)。

对于每个服务,我们都有一个实现和他的接口。但老实说,我很确定对于一项服务和他的接口,我们永远不会有多个实现。所以好吧,也许在接口中声明公共方法有助于了解服务的功能更清楚,但是接口用于有多个实现,如果我们知道我们不会有多个实现,我们应该保留他们?

【问题讨论】:

    标签: java model-view-controller


    【解决方案1】:

    我认为这是保留接口的好方法。

    原因: 1.说你想用不同的实现来写同样的junit。尽管从数据库中获取数据,但您希望从单独的数据源中获取数据,那么不同的实现就足够了。

    【讨论】:

    • 问题是关于服务层中的接口而不是关于 DAO(数据访问)层。
    【解决方案2】:

    来自documentation

    实现一个接口可以让一个类变得更加正式 它承诺提供的行为。接口形成契约 在班级和外界之间,并且这个契约被强制执行 在编译器构建时。

    如果您知道您将只有一个实现,则实现本身将定义合同,因此您可以删除接口。

    但是编写接口可以帮助您更好地定义合同,而且您可能需要在给定的时间点为服务编写模拟,在这种情况下,您将从使用接口中受益。

    【讨论】:

    • 我同意它可以帮助进行单元测试,但单元测试不应该驱动开发,不是吗?我没有提到它,但我们使用的是 Spring,并且不使用组件的接口有时会带来问题(因为 spring 使用的代理系统?)...
    • 我说的是模拟你的服务(返回一个实体的模拟列表只是为了看看你的视图是否正确地显示了集合)。在您的情况下,为了避免弄乱 Spring 代理,我肯定会使用接口。看看这个:stackoverflow.com/questions/11528061/…
    猜你喜欢
    • 1970-01-01
    • 2011-05-04
    • 2014-07-07
    • 2010-10-16
    • 2012-08-16
    • 2011-12-28
    • 2020-03-09
    • 2010-11-03
    • 1970-01-01
    相关资源
    最近更新 更多