⌘ K

Hand-Written Pattern

INFO

go-admin has two development patterns, chosen by how complex the business logic is:

The Actions Pattern — the default choice for single-table CRUD. The five common Actions in common/actions already cover parameter binding, data-permission filtering, actor injection, pagination and error responses, so a module needs only three files — model, dto and router — with no apis or service to write.
The Hand-Written Pattern (this page) — for when business logic goes beyond single-table CRUD (cross-table transactions, external calls, complex validation), where you write the Handler and Service yourself.

A compiled, complete example lives in the repository's app/demo/ directory — where this page and that directory disagree, the directory is authoritative.

First, a look at the structure — this is specific to the app directory:

bash

.
└── admin
    ├── apis
    ├── models
    ├── router
    └── service

admin: think of it as one project.

apis: the project's API files.

models: the project's database-layer models.

router: the project's routes.

service: the project's business logic.

service/dto: the models for receiving and parsing the data behind the project's APIs.

With that out of the way, let's move on.

The walkthrough below uses real code from the project — operation logging, as an example.

The order is: models, service/dto, service, apis, router.

Each of these modules can be reviewed individually, in that order.

WARNING

Where to get help:

If anything in this guide is unclear, please open an issue.

‌
‌
‌
‌

Hand-Written Pattern

INFO

go-admin has two development patterns, chosen by how complex the business logic is:

The Actions Pattern — the default choice for single-table CRUD. The five common Actions in common/actions already cover parameter binding, data-permission filtering, actor injection, pagination and error responses, so a module needs only three files — model, dto and router — with no apis or service to write.
The Hand-Written Pattern (this page) — for when business logic goes beyond single-table CRUD (cross-table transactions, external calls, complex validation), where you write the Handler and Service yourself.

A compiled, complete example lives in the repository's app/demo/ directory — where this page and that directory disagree, the directory is authoritative.

First, a look at the structure — this is specific to the app directory:

bash

.
└── admin
    ├── apis
    ├── models
    ├── router
    └── service

admin: think of it as one project.

apis: the project's API files.

models: the project's database-layer models.

router: the project's routes.

service: the project's business logic.

service/dto: the models for receiving and parsing the data behind the project's APIs.

With that out of the way, let's move on.

The walkthrough below uses real code from the project — operation logging, as an example.

The order is: models, service/dto, service, apis, router.

Each of these modules can be reviewed individually, in that order.

WARNING

Where to get help:

If anything in this guide is unclear, please open an issue.

TABLE OF CONTENTS

TABLE OF CONTENTS

Hand-Written Pattern

INFO

WARNING

Hand-Written Pattern

INFO

WARNING