tegwick
ed33766c91
Reorganize examples directory into logical topic-based subdirectories with comprehensive documentation: - templates/: ISO/ARC42 documentation templates - asset-management/: Asset management prototypes and demos - essays/: Long-form content examples - invoicing/: Invoice generation examples - plugins/: Plugin development examples - issue-demos/: Issue prevention demonstrations - design-patterns/: Design pattern examples Each subdirectory includes a README.txt file with topic description and contributor signatures based on file creation timestamps. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
124 lines
3.6 KiB
Markdown
124 lines
3.6 KiB
Markdown
---
|
|
pattern_name: "Repository Pattern"
|
|
category: "Data Access"
|
|
difficulty: "intermediate"
|
|
languages: ["Java", "C#", "Python", "TypeScript"]
|
|
related_patterns: ["Unit of Work", "Data Mapper", "Active Record"]
|
|
version: "1.0"
|
|
author: "Design Patterns Team"
|
|
date_created: "2025-10-02"
|
|
status: "published"
|
|
---
|
|
|
|
# Repository Pattern
|
|
|
|
Pattern Type: Behavioral
|
|
Category: Data Access Patterns
|
|
Difficulty Level: Intermediate
|
|
|
|
## Intent
|
|
|
|
Encapsulate the logic needed to access data sources. The Repository pattern centralizes common data access functionality, providing better maintainability and decoupling infrastructure or technology used to access databases from the domain model layer.
|
|
|
|
## Problem
|
|
|
|
Direct database access from business logic creates:
|
|
- **Tight Coupling**: Business logic depends on specific data access technology
|
|
- **Code Duplication**: Similar queries repeated across the application
|
|
- **Testing Difficulties**: Hard to unit test without actual database
|
|
- **Technology Lock-in**: Difficult to change data access technology
|
|
|
|
Problem Context: Large applications with complex data access requirements
|
|
Impact: High maintenance cost, reduced testability, technology dependencies
|
|
|
|
## Solution
|
|
|
|
Create a uniform interface for accessing domain objects that:
|
|
1. **Abstracts Data Access**: Hide implementation details behind interface
|
|
2. **Centralizes Queries**: Common data access logic in one place
|
|
3. **Enables Testing**: Interface allows for easy mocking
|
|
4. **Supports Multiple Sources**: Can work with different data stores
|
|
|
|
Solution Approach: Interface-based abstraction layer
|
|
Key Benefit: Separation of concerns between domain and data access
|
|
|
|
## Structure
|
|
|
|
```
|
|
Repository Interface → Concrete Repository → Data Source
|
|
↑ ↓
|
|
Domain Layer Infrastructure Layer
|
|
```
|
|
|
|
## Implementation
|
|
|
|
Implementation Language: Python
|
|
Framework: SQLAlchemy
|
|
Database: PostgreSQL
|
|
|
|
```python
|
|
# Repository Interface
|
|
class UserRepository(ABC):
|
|
@abstractmethod
|
|
def find_by_id(self, user_id: int) -> Optional[User]:
|
|
pass
|
|
|
|
@abstractmethod
|
|
def find_by_email(self, email: str) -> Optional[User]:
|
|
pass
|
|
|
|
@abstractmethod
|
|
def save(self, user: User) -> User:
|
|
pass
|
|
```
|
|
|
|
## Consequences
|
|
|
|
**Benefits:**
|
|
- ✅ Improved testability through dependency injection
|
|
- ✅ Separation of concerns between domain and data access
|
|
- ✅ Centralized data access logic reduces duplication
|
|
- ✅ Technology independence in domain layer
|
|
|
|
**Drawbacks:**
|
|
- ❌ Additional abstraction layer increases complexity
|
|
- ❌ May lead to over-engineering for simple applications
|
|
- ❌ Performance overhead from abstraction
|
|
- ❌ Learning curve for developers
|
|
|
|
Trade-offs: Flexibility vs. Complexity
|
|
When to avoid: Simple CRUD applications, prototype projects
|
|
|
|
## Known Uses
|
|
|
|
- **Enterprise Applications**: Banking systems, e-commerce platforms
|
|
- **Domain-Driven Design**: Clean architecture implementations
|
|
- **Testing Scenarios**: Applications requiring extensive unit testing
|
|
- **Multi-tenant Systems**: Applications with multiple data sources
|
|
|
|
Real-world Examples: Spring Data repositories, Entity Framework repositories
|
|
|
|
---
|
|
|
|
```yaml tailmatter
|
|
qa_checklist:
|
|
- requirement: "Code examples tested and verified"
|
|
complete: true
|
|
- requirement: "Related patterns cross-referenced"
|
|
complete: false
|
|
- requirement: "Real-world examples validated"
|
|
complete: true
|
|
|
|
editorial:
|
|
status: "review_complete"
|
|
reviewer: "architecture.team@example.com"
|
|
version: "1.0"
|
|
approval_required: false
|
|
last_updated: "2025-10-02"
|
|
|
|
pattern_metadata:
|
|
complexity_score: 6.5
|
|
usage_frequency: "high"
|
|
maturity_level: "stable"
|
|
community_rating: 4.2
|
|
``` |