REN Repository

RENRepository is REN.Kit’s default, generic repository for all your database operations. It encapsulates all the core CRUD logic and querying patterns, giving you a consistent and robust way to interact with your data models—without repetitive boilerplate.

---

How Should I Use RENRepository?

While RENRepository can technically be constructed directly, the recommended and safe usage is always through the Unit of Work (UoW) abstraction—never via direct injection or manual instantiation.

---

Why use RENRepository via Unit of Work?

• Transaction Safety: All changes and queries performed via a repository are tracked by the Unit of Work. This means when you call SaveChanges() or BeginTransaction(), all your operations are wrapped atomically—ensuring either everything is committed or nothing is.

• Consistency: By going through the UoW, your repositories always operate on the same DbContext instance, which avoids subtle bugs caused by context mismatches and ensures a consistent change tracking environment.

• Best Practices: Managing repositories through UoW keeps your codebase clean, testable, and compliant with enterprise data access patterns.

• Centralized Lifecycle Management: The UoW handles the disposal and lifecycle of the DbContext and any open transactions, so you don’t have to.

public class EmployeeService
{
    private readonly IRENUnitOfWork<RenDbContext> _unitOfWork;

    public EmployeeService(IRENUnitOfWork<RenDbContext> unitOfWork)
    {
        _unitOfWork = unitOfWork;
    }

    public async Task<List<Employee>> GetAllEmployeesAsync()
    {
        var employeeRepo = _unitOfWork.GetRepository<Employee>();
        return await employeeRepo.GetListAsync();
    }
}

Avoid direct injection:

Never register or inject RENRepository directly! All repository usage should be managed by the UoW, so transaction handling, change tracking, and data consistency are all guaranteed.

---

Entity-Based Custom Repository: Flexibility with Control

REN.Kit DataKit allows you to define custom repositories for specific entities—only where you need advanced logic or business rules. You’re not forced to create a custom repository for every entity; simply use the default repository for basic CRUD and extend only where required.

This pattern offers:

• Maximum flexibility: Apply specialized data access patterns only to the entities that require it.

• Reduced boilerplate: No need to maintain unnecessary custom repositories across your whole domain.

• Domain-driven design compatibility: Perfect for complex business domains where not every aggregate or entity needs the same infrastructure.

While this approach is extremely powerful, it also requires good project documentation and clear guidelines. We recommend maintaining an up-to-date mapping of which entities use custom repositories to keep onboarding, maintenance, and testing efficient.

With REN.Kit, you can combine flexibility and simplicity—scaling your data access patterns as your project grows!