Overview
Ensure a class has only one instance
Singleton Pattern
2 implementations available
When to Use
- When you need to abstract data access logic
- When you want to make your code testable
- When you need to support multiple data sources
- When you want to decouple business logic from infrastructure
Available Implementations
Cloudflare Workers
Hono server for Cloudflare Workers with typed bindings
npx hanma add hono-cloudflare-workers --framework hono
Typed bindings for KV, D1, R2Edge caching with cache() middlewareGeo context (colo, country, city)
Error Handler
Global error handling with custom error classes
npx hanma add hono-error-handler --framework hono
Custom error classesProduction-safe messagesHTTP exception handling
Basic Example
// Singleton Pattern implementation example
// This shows the basic structure of singleton pattern in Hono
// Define your interface
interface IRepository {
findAll(): Promise<T[]>;
findById(id: string): Promise<T | null>;
create(data: CreateDto): Promise<T>;
update(id: string, data: UpdateDto): Promise<T>;
delete(id: string): Promise<void>;
}
// Implement the pattern
class SingletonRepository implements IRepository {
async findAll(): Promise<T[]> {
// Implementation
}
async findById(id: string): Promise<T | null> {
// Implementation
}
async create(data: CreateDto): Promise<T> {
// Implementation
}
async update(id: string, data: UpdateDto): Promise<T> {
// Implementation
}
async delete(id: string): Promise<void> {
// Implementation
}
}
// Use the pattern
const repository = new SingletonRepository();
const items = await repository.findAll();
Frequently Asked Questions
What is Singleton Pattern?
Ensure a class has only one instance. It's a well-established software design pattern that helps organize code for better maintainability and testability.
How does Singleton Pattern work with Hono?
Hono provides excellent support for this pattern through its dependency injection system and middleware composition.
What are the benefits?
Improved testability, separation of concerns, easier maintenance, and flexibility to change implementations without affecting business logic.
When should I avoid this pattern?
For very simple applications with minimal logic, the pattern may add unnecessary complexity. Use judgment based on project requirements.