How to understand the design idea of the framework from the perspective of developers?

Thanks for the support

I have published more than 100 original articles on CSDN. If you have read my articles, please click the link below and give me a five-star evaluation, thank you.

It's very simple, just click the picture below and give a five-star rating like the screenshot :

answer all questions

Recently, many readers have privately messaged me, why did you choose GoFrame for the development of e-commerce projects?

the reason is simple:

Because our company uses GoFrame for e-commerce business development, and our colleagues basically convert PHP to Go. GoFrame can be said to be a very suitable development framework for PHPer to Gopher.

Before joining our company, I used Gin and go-micro framework, and I am currently learning go-zero.

Whether it is the development language or the development framework, they all serve the business we do. It is meaningless to talk about the language or the framework regardless of the business.

Another reason for using GoFrame as an open source project is: I want to experience the new features of the V2 version, and I can have the final say on how to do my own project without historical burden.

foreword

Let developers better achieve "high cohesion inside modules, loose coupling between modules" is the essence of GoFrame V2 design in my opinion.

It has been a long time to develop commercial projects with GoFrame. I found that the version of GoFrame is updated relatively quickly, and the community is also very active.

Due to historical reasons, I have been using the V1.16 version to develop commercial projects, although I personally have a strong desire to upgrade to V2.

However, due to reasons such as project stability and development costs, commercial projects have not been upgraded. This may also be a problem faced by many small partners.

be encouraged

Just some time ago, I shared my open source project [Go WEB Advanced Practice] The e-commerce front-end and back-end API system based on GoFrame
has received everyone's attention and support, and the author of GoFrame also likes and forwards it, which is even more encouraged.

More importantly: I have received suggestions from many small partners in the community. The most suggestion is to suggest that I use the V2 version, because it provides many new features, which can better meet the needs, and is stable and efficient.

decided to upgrade

So, I decided to upgrade my open source project from version V1.16.x to the latest version V2.2.0, step on the pit of the upgrade, and enjoy the happiness after the upgrade.

Friends are welcome to join my open source project: e-commerce front-end and back-end system API , the current V1 version has been completed, including common functions of e-commerce projects, and more than 120 interfaces have been developed.

participate together

In the development process of the V2 version, more than 30 interfaces have been developed so far. It is planned to complete the development within this month and open source it. Friends are welcome to participate in the joint construction, and welcome to read my source code and give more valuable suggestions:

V2 version GitHub address

Because the content is relatively long and hard-core, I decided to share it in two articles:

1. The focus of this article: introduce the new features of GoFrame V2, and what are the advantages compared with V1? What is the biggest change?

2. I will share it in the next article: My journey of stepping on the pit from V1 to V2, I believe it will be helpful to many friends.

This experience is really not easy, I hope that friends can like, follow, and forward a wave.

Suitable for the crowd

1. After mastering the basics of Go, partners who want to use a mature framework to develop projects are recommended to use the latest V2 version of GoFrame for actual development after reading my article.
2. Currently using the V1 version, those who are willing but do not have a lot of energy to learn the new features of V2, and those who are worried about the upgrade problem and dare not upgrade rashly.
3. Friends who want to improve their efficiency in learning new knowledge are welcome to replicate my practice.

From a developer's point of view

No matter what kind of people you are, it is recommended to take the time to read the official documents carefully, especially the introduction of the framework .

Different from official documents, this article will combine my own experience, from the perspective of frame users, to help you understand the design ideas of Goframe V2 version faster and better, and how to better develop commercial projects based on V2 version .

stepped on the pit

In the process of upgrading the version, I found that: you must first understand the new features of V2, and then upgrade from V1 to V2, otherwise there will be problems when you upgrade halfway:

1. Because the dao and model generated by the V2 version of the CLI tool are inconsistent with the V1 version: the gmvc module is discarded, and new modules are also introduced.

2. The method supported by the V2 version gf gen servicegenerates the service layer, unifies the implementation of our interface logic, and introduces the concept of logic layer and service layer

Combined with my own upgrade experience, I will share with you the knowledge points you must know when learning GoFrame V2:

must know must know

1. The project structure has changed, and it needs to follow the V2 standard, because the directory structure of the code generated by the gf tool has changed, and more importantly: the directory structure officially recommended by V2 is also better for us to practice "high cohesion and low coupling" project directory structure.

2. gf gen daoIn addition to generating the dao layer and model layer like V1, the do layer and entity layer will also be generated

3. The directory structure of the V2 version practiced the idea of ​​decoupling the business model and the data model (which is also what I think is very good)

4. Compared with V1, methods or modules will be discarded in V2, such as the gmvc coupling module, which will not be further supported in the future. At the same time, it also provides us with a better way to achieve it.

5. V2 is a bit like writing "microservices", which requires service registration: the controller calls one or more services to implement specific business logic; however, complex business logic is not implemented in the service. In order to decouple, the V2 version introduces logic Directory for writing and reusing complex business logic. Register the service in logic, and standardize the method to be implemented in the logic layer through the interface in the service.

top priority

Let me introduce the knowledge points that took me a long time to digest:

dao code generation (very important)

gf gen dao

In business projects, it is officially recommended to use the dao/do/entity method to operate the database. These files are automatically generated by the development tools and maintained uniformly by the development tools.

Different from the V1 version, the V2 version introduces the concept of do, why is it designed like this?

Here I only talk about the conclusion, and the official link will be attached at the end of the article:

1. The dao layer is used for data access, which is a layer of abstract objects used to interact with the underlying database, including only the most basic CURD methods

2. The model layer is a structural model, a data structure management module, which manages data entity objects and defines input and output data structures.

   2.1 The do in the model is a domain object, which is used to convert the business model and the instance model in the dao data operation. It is maintained by the tool and cannot be modified by the user.

   2.2 The entity in the model is the data model, and the data model is a one-to-one relationship between the model and the data collection, which is maintained by the tool and cannot be modified by the user.

Later I will take you to explain with examples

Service interface generation (more important)

gf gen service

The service interface is a very important knowledge point, and I think it is the biggest difference between the cli tool support and the V1 version:

In order to reduce the coupling between modules in the business project, the framework abstracts the dependencies between modules into interfaces, which are maintained by the internal/service package. The internal/service can be customized by the developer to maintain the interface, or the interface code file can be automatically generated according to certain rules through the code encapsulated by the internal/logic business.

Real knowledge comes from practice

Reading the document 10 times is not as good as practicing it once. I suggest everyone to practice with me, welcome to reproduce:

My train of thought is this:

1. Download the official sample project and learn how the official is written.

2. Put forward requirements for yourself, refer to official implementation methods, and realize your own business scenarios.

3. I will take you to realize the classic e-commerce scenario: adding and querying product information.

1. Download and run official samples from GitHub

Official sample GitHub

1.1 After downloading and deploying the project, start: very smooth and start successfully:

1.2 Request the interface, and verify that the DB is connected normally.

1.3 Querying the database is also valuable.

After verifying that the environment is correct, let's take you to refer to the official examples to realize your own needs, so as to better understand the new features and engineering practices of the V2 version.

2. Write commodity management based on V2

Let's practice according to the official engineering method to see if we will step on the pit:

2.1 Create the goods table as follows:

2.2 Generate dao and model through gf gen dao

The first attempt failed because the config.yaml configuration file in the hack directory was not modified.

Note: Different from V1, the official said that the hack directory is used for tool scripts, storing project development tools, scripts and other content. For example, the configuration of CLI tools, various shell/bat scripts and other files. So we don't write the configuration file of the cli tool into the manifest/config directory like V1.

2.3 Done, successfully generated.

Tip, if we don't specify tables, the data corresponding to all tables will be generated. I prefer to do this: because it can avoid changing multiple tables by myself, but missing a certain table in the configuration file will cause unexpected problems.

Let's start to code officially:

I will first write in a way that is easy for everyone to understand. At the end of the article, I will share my practical experience: in what order to write the code of each module is more scientific.

2.4 First we implement the api layer and define the structure of the request and response

2.5 We register Goods-related routes in cmd

2.6 We found that when registering a route, controller.Goods is red because we haven't written this method yet.

We refer to the sample code to write the controller layer:

We found that in the sample project on the right, the method internally calls the method in the service, but we have not defined the service yet, what should we do?

Let's first click on user.go in the sample project to see what is defined in the service:

After consulting the documentation, I learned that:

We need to realize the business logic by writing the logic layer, and automatically generate the service code by configuring the goland plug-in.

If this is the best practice recommended by the official:

2.7 Import the official xml file (you only need to configure it once)

xml file address

It is strongly recommended that you do this. After this configuration, when we write the logic layer code, the service can automatically generate the interface definition file.

Of course, you can also not configure it, but you need to manually execute the gf gen service command every time after the logic business module is developed/updated. Too much trouble! ! !

2.8 We refer to the example on the right to write the logic code of goods to process business logic:

2.9 After testing, I found that after writing the logic logic, the corresponding goods files and methods are automatically generated in the service layer, which is very convenient.

2.10 Let's continue to write the logic of adding products and viewing products

We found that after writing the logic of adding products in the logic layer, the code is automatically generated in the service layer on the right.

2.11 Careful students may have discovered the RegisterGoods method of the service layer. Why is this used?

The answer is: after we generate the RegisterXX() method in the service layer, we need to add the implementation injection of the interface in the corresponding business module.

Tip: This method can be added once for each business module.

It is recommended that after writing the first logic method (or after the service layer generates the RegisterXX method):

1. Realize the registration of the service in the init function of the logic layer;

2. Then check whether the logic.go file has added relevant dependencies, if not, you can add it manually;

To develop good coding habits, less bugs.

2.12 We checked the logic.go file in the logic directory and found that the import related to the goods we wrote this time has been automatically added:

The function of this file is to register the specific implementation of the interface when the program starts.

Well, this is the end of logic and service, and we have completed the writing of business logic.

There is a lot of content, you can scroll up and read this part again, digest and absorb it.

2.13 Let's go back and continue to write the code of the controller layer:

We refer to the official controller/user.go to implement our own controller/goods.go method of adding goods:

2.14 At this point, we have completed the writing of new requirements, start the service to check the effect:

Very OK, I have seen the corresponding interface.

After coding, test it:

Let's request the interface and add data to see:

The data is also viewed in the database: the insertion is successful, and the process goes through!

Reflection review

Follow the above process down, although the overall run through. Personally, I feel rather confused.

It took me a long time to digest and absorb the engineering practices of official documents, combined with my own experience.

Let's sort out the writing process of the V2 project again. My suggestion is as follows :

Finishing process

1. design table structure

2. Use to gf gen daogenerate the corresponding dao/do/model directory code

3. Write the api layer: define the data structure of the "business module", and provide the input/output data structure of the external interface

4. Write the model layer: define the data structure of the "data module", and provide the input/output data structure for internal data processing

5. Write the logic layer and automatically generate the service layer code. ( Automatically generated by configuring goland File Watcher , or manually executed script generation through gf gen service, the former is strongly recommended)

6. After the service layer code generates the RegisterXX() method, register the service in the corresponding logic module (each module only needs to be written once)

7. Write the controller layer, receive/parse the parameters input by the user, and call the services of the service layer.

8. Register the route and expose the interface to the outside world. For example, this project is to write the cmd.go file.

9. Add a line_ "project-name/internal/logic" in main.go (only need to write once)

10. In main.go add a line _ "github.com/gogf/gf/contrib/drivers/mysql/v2" (if you are using mysql; just write it once)

key process

1. Only 3~8 of the above steps are required for each new development requirement
2. Steps 1 and 2 are very simple to design the table structure and automatically generate codes, which are only required when adding or modifying tables
3. Steps 9 and 10 can be written once when creating a project

practice again

I followed the above steps to write the query product logic, and the overall process is very smooth:

Friends, let’s practice it too. Welcome to star fork my open source project: https://github.com/wangzhongyang007/goframe-shop-v2

learn with questions

I have some doubts when writing commodity management requirements:

Why do I need to define the data structure twice? I defined it once at the api layer and again at the model layer. I wrote the repeated structure twice. What's the point?

I calmed down and thought about it. This design is still worth deliberating. I will share my understanding based on my previous project experience. If you have any understanding, please leave a message in the comment area.

previous problems

We have encountered the problem of difficult maintenance when developing the unified storage of commodity centers before, because the business logic and data processing logic are coupled together.

With the increasing complexity of the business, the maintenance cost of the project is getting higher and higher, even reaching the level of difficult maintenance.

How did we solve it?

The solution is to decouple the data model and business model of GoFrame, and the underlying idea is the same:

We split the complex logic: define business modules and data processing modules.

"Business module": only handles the received parameters, and does not care about how to store and retrieve values. According to the requirements of the "data module", process the data incoming from the front end, and pass the unified structure to the "data module".

"Data Module": You don't need to care about the specific implementation of "Business Module". A unified input standard is defined, and business modules are required to uniformly import data according to their own requirements. The focus of data module consideration is how to insert data in batches efficiently. How to efficiently get values ​​on-demand does not need to care about changing business-side requirements.

Sublimate

After dismantling the redundant modules, we sorted out the boundaries between "data modules" and "business modules". We not only solved the problem of difficult maintenance of previous projects, but also improved our ability to flexibly meet customer needs.

Combined with my own project experience and the experience of practicing the V2 version this time, I started by saying: Let developers better achieve "high cohesion inside modules and loose coupling between modules", which is the essence of GoFrame V2 design in my opinion.

Alright, that’s all for this article. It’s 5,000 words hardcore. It’s not easy to insist on updating. Everyone is welcome to like, comment, and forward.

at last

If you think the content of this issue is good, you must support it three times in a row.

There is my official account card below, welcome to scan the code to follow, and receive free hard-core programming materials.