Base Classes Documentation¶
This document provides an overview of the base classes implemented for the PRS Backend project as part of the DDD refactoring effort.
Overview¶
The following base classes have been implemented:
- BaseRepository: Provides standard data access methods for repository layer implementations.
- BaseService: Provides common CRUD operations and utilities for service layer implementations.
- BaseController: Provides standard response handling for controller layer implementations.
These base classes are designed to be extended by concrete implementations to reduce code duplication and ensure consistency across the codebase.
BaseRepository¶
The BaseRepository class provides standard data access methods for interacting with the database.
Location¶
| Text Only | |
|---|---|
Usage¶
| JavaScript | |
|---|---|
Available Methods¶
create(payload, options): Creates a new recordupdate(where, payload, options): Updates existing recordsfindOne(payload): Finds a single recordfindAll(payload): Finds all records with pagination supportgetById(id, options): Gets a record by IDdestroy(where, options): Deletes recordsupsert(payload, options): Creates or updates a recordbulkCreate(payload, options): Creates multiple recordscount(payload): Counts recordsupdateById(id, payload, options): Updates a record by IDdestroyById(id, options): Deletes a record by IDfindByIds(ids, options): Finds records by a list of IDs
BaseService¶
The BaseService class provides common CRUD operations and utilities for service layer implementations.
Location¶
| Text Only | |
|---|---|
Usage¶
| JavaScript | |
|---|---|
Available Methods¶
withTransaction(callback): Executes a callback within a transactioncreate(repository, data, options): Creates a new recordupdate(repository, where, data, options): Updates an existing recorddelete(repository, where, options): Deletes a recordgetById(repository, id, options): Gets a record by IDgetAll(repository, query): Gets all records with pagination
BaseController¶
The BaseController class provides standard response handling for controller layer implementations.
Location¶
| Text Only | |
|---|---|
Usage¶
Available Methods¶
sendSuccess(reply, data, statusCode, message): Handles successful responsesendCreated(reply, data, message): Handles created responsesendNoContent(reply): Handles no content responsehandleError(error): Handles error responsevalidate(schema, data): Validates request data against a schemaexecuteAction(action, request, reply): Executes a controller action with error handlingcreateAction(handler): Creates a controller action with standard error handling
Example Implementations¶
Example implementations of each base class are provided:
ExampleRepository:src/infra/repositories/exampleRepository.jsExampleService:src/app/services/exampleService.jsExampleController:src/app/handlers/controllers/exampleController.js
These examples demonstrate how to extend and use the base classes in your own implementations.
Best Practices¶
- Always extend the base classes: Don't copy and paste the base class methods into your implementations.
- Use the provided methods: The base classes provide common methods that should be used instead of reimplementing them.
- Add custom methods: Extend the base classes with your own custom methods for domain-specific functionality.
- Use transactions: Use the
withTransactionmethod in services for operations that require multiple database changes. - Handle errors properly: Use the provided error handling methods in controllers.
- Validate input: Use the
validatemethod in controllers to validate request data against schemas.
Benefits¶
Using these base classes provides several benefits:
- Reduced code duplication: Common functionality is implemented once and reused.
- Consistent error handling: Errors are handled consistently across the application.
- Standardized responses: API responses follow a consistent format.
- Transaction support: Database transactions are handled consistently.
- Pagination support: Pagination is handled consistently across the application.
- Improved maintainability: Changes to common functionality only need to be made in one place.