RCommon
HomeGitHub
  • Introduction
  • Common Scenarios
  • Getting Started
    • Running Examples
    • Roadmap
    • Releases
      • 1.0.1.75
      • 1.0.2.0
      • 2.0.0
      • 2.1.0
  • Topics
    • Fundamentals
      • Configuration
      • Logging
      • GUID Generation
      • Time and Date
      • Emailing
        • SMTP Email
        • SendGrid Email API
      • Data Transfer Objects
        • Pagination
      • Security
        • Current User
        • Claims
      • Events
        • Transactional Events
        • Synchronous Events
        • Asynchronous Events
        • Producers
        • Subscribers
      • Validation
        • Fluent Validation
      • Caching
        • Dynamically Compiled Expressions
        • Persistence Caching
        • Caching Services
        • Redis & Valkey
        • Memory Cache
      • Serialization
        • JSON.NET
        • System.Text.Json
    • Patterns
      • Specification
      • Mediator
        • MediatR
          • Validator Behavior
          • Unit of Work Behavior
          • Logging Behavior
      • CQRS
        • Commands
        • Queries
      • Persistence
        • Repository
          • Entity Framework Core
          • Dapper
          • Linq2Db
        • Transactions
          • Unit of Work
      • Event Bus
        • In Memory
        • MediatR
        • Wolverine
      • Message Bus
        • MassTransit
        • Wolverine
    • Architecture
      • Overview
      • Microservices
      • Clean Architecture
      • Event Driven Architecture
  • Examples
    • Clean Architecture
    • CQRS
    • Mediator: MediatR
    • Event Handling: In Memory
    • Event Handling: MediatR
    • Event Handling: MassTransit
    • Event Handling: Wolverine
    • Validation: Fluent Validation
Powered by GitBook
On this page
  1. Topics
  2. Patterns

Persistence

Persistence through the RCommon Framework ensures a consistent programming experience no matter what the underlaying data provider may be.

PreviousQueriesNextRepository

Last updated 1 year ago

Persistence is a subject near and dear to our collective heart. As it is involved in most modern applications be it transactional databases, or document databases, we a have near daily need to persist and retrieve information from various data providers.

Most of our persistence strategies revolve around the need for the pattern in conjunction with the with or without a requirement for distributed transactions. If you have a simple application with basic persistence needs, then feel free to skip all this and move on. But for larger applications, and especially enterprise applications - the need for persistence and the use cases we solve for below is an absolute must have.

Use Cases for Persistence

  • Use the Unit of Work pattern but not be tied to a specific ORM or tool.

  • Built-in support for and .

  • Built-in support for change tracking via entity base classes.

  • Consistent programming interface no matter which ORM you're using.

  • Freedom to create your own Repository pattern implementation and still utilize everything RCommon persistence offers.

unit of work (UoW)
repository pattern
domain events
distributed events