Shulou(Shulou.com)06/03 Report--

This article mainly explains why the Service layer does not need an interface. The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn why the Service layer does not need an interface.

Reasons for not needing an interface

I sorted out the reasons why interfaces need to be added to support the Service layer and the Dao layer, and summed up just three:

You can write upper-layer code without implementing specific Service logic, such as Controller's call to Service.

By default, Spring implements AOP based on dynamic agents, which require interfaces.

Multiple implementations of Service can be implemented.

In fact, none of these three reasons are tenable!

Let's start with the first reason: the upper layer can be coded without the implementation of the lower logic! Typical interface-oriented programming, decoupling between layers, seems to be no problem.

This kind of development method is suitable for different modules to be developed by different people or project teams, because the cost of communication is high. At the same time, avoid mutual influence due to differences in development progress between project teams.

But let's recall, in general project development, how many project teams divide development tasks by layer? In fact, most projects are divided by function.

Even in the case of separation of front and rear ends, pure back-end development is divided into tasks according to functional modules, that is, one person is responsible for the complete logic processing from the Controller layer to the DAO layer.

In this case, each layer defines an interface first, and then implements the logic, in addition to increasing the developer's workload (of course, if the amount of code is counted as the workload, the developer should not reject the interface too much). It's of no use.

If the developer wants to develop the upper-level logic first without the completion of the lower-level logic, he can first write an empty method of the lower-level class to complete the upper-level logic first.

Here, we recommend a personal favorite development process, the top-down coding process:

First write the logic in the Controller layer, and when you encounter a place where you need to delegate the Service call, write the calling code first. Priority is given to completing the process of the Controller layer.

Then use the automatic completion of IDE to generate the corresponding classes and methods for the code that just called the lower layer, and add TODO to it.

All the classes and methods are completed, and then based on TODO, follow the above process to improve the logic one by one.

This method can give you a better understanding of the business process.

For the second reason, it is totally untenable. Spring is based on dynamic proxies by default, but AOP can be implemented using CGLib through configuration. CGLib does not require an interface.

The final reason is that multiple implementations of Service can be implemented. This is not a good reason, or does not consider the scenario. In fact, in most cases, multiple implementations are not required, or interface-based multiple implementations can be replaced in other ways.

In addition, for many projects that use interfaces, the project structure is also open to question! Next, we will explain it in combination with the project structure.

Project structure and Interface implementation

The general project structure is divided by layer, as follows:

Controller

Service

Dao

For cases where no more implementation is required, there is no need for interfaces. The above project structure can meet the requirements.

For situations that require more implementation, either now or later. In this case, it looks as if an interface is needed.

The project structure at this time looks like this:

Controller

Service

-the interface is in a package

Impl-implemented in another package

Dao

For the above structure, let's consider what to do in the case of multiple implementations.

The first way is to add a package to Service, write new logic in it, and then modify the configuration file to use the new implementation as the injection object.

As follows:

Controller

Service

-the interface is in a package

Impl-implemented in another package

Impl2-the new implementation is in another package

Dao

The second way is to add a new Service module and write new logic in it. (note that the package here cannot be the same as the original Service package, or the package is the same, but the class name is different, otherwise the class cannot be created. Because two Service modules need to be loaded at the same time, if the package name and class name are the same, the fully qualified class names of both modules will be the same), and then modify the configuration file to use the new logic as the injection object.

As follows:

Controller

Service

-the interface is in a package

Impl-implemented in another package

Service2

Impl2-the new implementation is in another package

Dao

Relatively speaking, the actual first approach is relatively simple and only needs to focus on the package level. The second approach needs to focus on both the module and the package.

In addition, both approaches actually result in unwanted logic code in the project. Because the old logic will be put into the bag.

However, from a structural point of view, the structure of actual mode 2 is clearer than that of mode 1, because logic can be distinguished from modules.

Is there any way to combine the advantages of the two? The answer is yes, and it is not complicated to operate!

First of all, the interface and implementation are separated as a separate module:

Controller

Service-Interface Module

ServiceImpl

Impl-implemented in another package

ServiceImpl2

Impl2-the new implementation is in another package

Dao

Second, adjust the packaging configuration, ServiceImpl and ServiceImpl2 choose one of the two. Since ServiceImpl and ServiceImpl2 choose one of the two, the package structure of ServiceImpl and ServiceImpl2 can be the same.

The package structure is the same, so after adjusting the dependencies, the configuration related to dependency injection does not need to be adjusted.

After adjustment, the project structure looks like this:

Controller

Service-Interface Module

ServiceImpl

Impl-implemented in another package

ServiceImpl2

Impl-the new implementation is in the same package as honest now.

Dao

Now, the package structure and class name in the ServiceImpl and ServiceImpl2 modules are the same. Do we still need the interface module?

Suppose we remove the Service interface module and change the structure to look like this:

Controller

Service1-Old implementation

Service2-New implementation

Dao

Can multiple implementations of Service be realized simply by adjusting module dependencies? Isn't the answer obvious?

The disadvantage of not using an interface

The reasons for not using the interface are given above. However, not using interfaces is not entirely without drawbacks. The main problem is that there is no strong interface specification for multiple implementations.

In other words, the framework code can not be generated quickly with the help of IDE through the implementation of the interface. IDE can also give error alerts to interfaces that are not implemented.

A less elegant solution is to copy the code from the original module into the new module and implement the new logic based on the old code.

Therefore, if a project requires multiple implementations, and the number of multiple implementations is large (although a typical project does not have multiple implementations), interfaces are recommended. Otherwise, you do not need to use the interface.

Thank you for reading, the above is the content of "Why the Service layer does not need interfaces". After the study of this article, I believe you have a deeper understanding of why the Service layer does not need interfaces, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.