Go language middleware design: How to avoid multiple business modules relying on the same complex business and causing bloated code?

golang Intermediate Business Layer Design Best Practices: Decoupling Solutions Based on Interface and Registration Mechanism

In the case where multiple business modules rely on the same complex business, how to design the intermediate business layer to avoid bloated code and difficulty in maintaining is an important design issue. This article will discuss a decoupling solution based on interface and registration mechanism for "create a" business, which can effectively solve the code accumulation problem caused by switch statements in the original solution.

In the problem description, multiple business modules such as abcd need to call "Create a" business, and perform their respective preprocessing and post-processing before and after the call. The original solution uses switch statements to distinguish it, which will become difficult to maintain when the number of business modules increases. Therefore, a more elegant and scalable solution is needed.

The core of the improvement solution is to utilize the interface characteristics and registration mechanism of the go language. We can define an interface handlepublica, which includes three methods: beforecreate, aftercreate and name, which represent the processing before creating a, the processing after creating a, and the identity of the business module.

Each business module (such as a, b, c, d) implements the handlepublica interface and implements specific preprocessing and postprocessing logic in their respective beforecreate and aftercreate methods. The name method returns the identifier of the business module.

Creating a business itself is used as an independent structure publica, and its do method contains core business logic.

Through this design, we can decouple the processing logic of each business module, avoiding the accumulation of switch statements. At runtime, we can register each business module through a handlepublica interface-type slice hooks, and then call their beforecreate and aftercreate methods in turn.

Here is a specific code example:

 type PublicAParam struct{} // Create data required for public service a type PublicA struct{} // Public service a
type PublicARes struct{} // Data generated by public service a func (p PublicA)Do(name string) PublicARes { // Business a's own processing logic return PublicARes{}
}

type HandlePublicA interface {
    BeforeCreate(PublicAParam)PublicA
    AfterCreate(PublicARes)
    Name() string
}

type A struct { // Other businesses A
    MyName string
}
func (a A)BeforeCreate(param PublicAParam) PublicA { return PublicA{} }
func (a A)AfterCreate(PublicARes){}
func (a A)Name() string { return a.MyName }

func main(){
    param := PublicAParam{}
    hooks := []HandlePublicA{A{MyName: "A"}}
    for i := range hooks{
        p := hooks[i].BeforeCreate(param)
        after := p.Do(hooks[i].Name())
        hooks[i].AfterCreate(after)
    }
}

In this example, the public structure represents "create a" business, the handlepublica interface defines the methods that the business module needs to implement, and the a structure implements the handlepublica interface and is registered in the hooks slice. By traversing hooks slices, we can call the processing logic of each business module in turn, realizing the decoupling and scalability of the business logic. The result returned after the publica.do method is processed and will be passed again to the aftercreate method of each business module for subsequent processing.

The above is the detailed content of Go language middleware design: How to avoid multiple business modules relying on the same complex business and causing bloated code?. For more information, please follow other related articles on the PHP Chinese website!