Built-in ORM and Custom ORM

Overview

1. Services created by sponge based on SQL (web, gRPC, gRPC+HTTP) use the built-in ORM component and do not support using a custom ORM component.

2. Services created by sponge based on Protobuf (web, gRPC, gRPC+HTTP) are not tied to a specific database component, allowing developers to flexibly choose between the built-in ORM component or a custom ORM component based on project needs. This design preserves architectural flexibility to meet the requirements of projects with different complexities.

   The main differences are:

   Step	Built-in ORM Component	Custom ORM Component
   1. Database connection config	Automatically generated	Developer needs to implement
   2. Model definition	Automatically generated	Developer needs to implement
   3. CRUD operations	Automatically generated	Developer implements database CRUD operations

Built-in ORM Component (Recommended)

• Features:
  • Integrates Gorm/MongoDB official drivers
  • Automatically generates complete CRUD API code (including DAO layer, Model layer, database connection, etc.)
  • Generated code automatically integrates into the project architecture, maintaining style consistency
• Applicable Scenarios: Standardized projects requiring rapid development

Tips

In the development guide, the chapter titled Add CRUD API introduces the use of the built-in ORM component.

Custom ORM Component

• Features:
  • Supports any ORM library (e.g., XORM, SQLX, Ent, etc.)
  • Requires developers to implement:
    • Database connection configuration
    • Model definition
    • DAO layer CRUD operations
  • Directory structure can be freely planned
• Applicable Scenarios:
  • Needs to interface with existing database architecture
  • Has special performance optimization requirements
  • Uses specific ORM features

If you prefer not to use the built-in ORM component, you can implement your own ORM component and configure database connection information via the configuration file.

Instructions for Using a Custom ORM Component

1. The database initialization code is located in the internal/database directory.
2. By default, there are no internal/model, internal/dao, etc., directories. Developers can customize the directory structure, such as creating an internal/repository directory, and place all data operation code there.
3. In code layers like handlers or services, you can then call its methods.