Java 服务接口和服务impl类的代码体系结构spring

我发现在MVC模式中，主要有4个类；控制器、服务、服务impl和repo

Service是一个接口，Service impl实现Service类并包含所有逻辑代码。结构将类似于：-

服务

接口

Service{

public void someMethod();

}

serviceinpl

class

 ServiceImpl implements Service{
  public void someMethod(){
   //do something

   }    
 }

但是，当我们想从控制器访问服务impl代码时，我们将服务类的方法称为：-

@Autowired 
Service service;

Object obj =  service.someMethod();

---

控制器如何执行ServiceImpl类的代码这基本上就是Spring的工作原理：

 ServiceImpl implements Service{
  public void someMethod(){
   //do something

   }    
 }

服务实现应该是一个Springbean（它必须有

@组件

或

@服务

注释，或者应该在SpringXML配置文件中定义），这样Spring才能找到它并在Spring应用程序上下文中注册它

然后通过

@Autowired

注释使用依赖项注入，将服务的实现注入控制器。这意味着Spring将查看您的控制器，它将在

服务

成员变量上找到

@Autowired

注释，并使用它在应用程序上下文中找到的bean对其进行初始化，该bean将是它先前注册的服务实现类的实例。因此，在Spring完成后，

service

将引用

serviceinpl

的实例

---

有关依赖项注入如何与Spring一起工作的信息，请参阅Spring框架参考文档：

当您使用注释@Autowired时，Spring将在其应用程序上下文中自动搜索要注入控制器中的候选项。有效的候选者应该是一个标记为Springbean的具体类，例如使用annotation@Service。

拥有这种体系结构背后的基本思想与Spring约定没有什么不同

假设明天您决定，您不希望两个项目都有一个应用程序，而是一个部署webapp，另一个部署service 例子 用户服务 网络应用

因此，为了让WebApp连接到UserService，它必须发出http请求来获取任何类型的数据。然后，您必须更改所有WebApp代码，使其与新更改兼容。例如，您将调用httpClient，而不是直接调用服务的方法。为了避免这种返工，您可以使用接口服务实现您自己的ServiceImpl并在其中发出所有http请求，其余的保持不变

类似的工作将在UserService中完成，它将像以前一样拥有自己的ServiceImpl，但将在控制器中作为单例对象调用

你的回答是:

---

您可以直接引用ServiceImpl，它将达到此目的，区别在于ServiceImpl不是当前模块或任何依赖项的一部分，但最终的捆绑项目将通过某个同级模块实现，可能

@Controller-Controller是您使用来自用户界面的请求的入口点，定义一组服务，并转储一个RequestMappingURI路径，该路径告诉后端的请求是什么，返回什么。然后，创建一组服务，在其中编写一组接口，然后继续创建一组服务实现文件，然后创建DAO。 关于Autowired的注意：它会自动带来您在中指定的实例 @服务-特定的类被视为服务，用于编写DAO事务。

---

@Autowired从某个地方带来了您需要的“实例”，通常我们会尝试从Autowired注释中找到您想要的“服务”，然后您可以添加@qualifier以避免混淆从类似bean中带来的具体实例。

那么，如果我们使用多个类实现

服务

接口，会发生什么？谁的实现代码将被执行。如果您有多个SpringBean实现了

服务

，那么在启动应用程序时会出现错误，因为Spring不知道选择哪一个。有很多方法可以告诉Spring选择哪一个，例如使用

@Qualifier

或

@Primary

。谢谢您的回答，先生。但是为什么春天会使用这种模式呢？我认为在正常的

mvc

模式中，接口类没有必要的角色。只需要强制

ServiceImpl

类实现一些方法，Spring并不一定需要接口。如果没有接口，它的工作原理也会完全相同。但是拥有接口的目的是分离实现，这样耦合就少了，而且它更容易，例如，为单元测试注入服务的模拟实现。假设您有一个StudentService，今天保存到MySQL。稍后您可能会得到一个新的需求，需要保存到Mongo plus Elastic Search。如果您只有服务类，您必须修改现有的服务类。如果您有一个接口，您只需添加另一个实现。您可以从另一个依赖项插入新的实现，即使不更改任何代码行。假设您需要这两个功能，但根据启动命令行参数选择该功能。然后您可以有多个实现和在运行时根据一些限定符进行选择。我认为可维护性是这里的关键。