Odpowiedź.

Wzorzec Repository enkapsuluje logikę dostępu do źródła danych (Baza Danych, API itd.), oferując warstwę abstrakcji między logiką domeny a mechanizmem przechowywania danych. Głównym celem jest ukrycie szczegółów implementacji przechowywania i zapewnienie pracy z kolekcją obiektów z zakresu tematycznego.

Zalety:

• Ułatwia testowanie dzięki możliwości podmiany źródła danych
• Sprzyja przestrzeganiu zasady pojedynczej odpowiedzialności
• Ułatwia migrację Bazy Danych, zmianę źródła danych lub proxy cache'ujących

Przykład kodu w C#:

public interface IUserRepository {
    User GetById(int id);
    void Add(User user);
}

public class UserRepository : IUserRepository {
    private readonly DbContext _context;
    public UserRepository(DbContext context) {
        _context = context;
    }
    public User GetById(int id) => _context.Users.Find(id);
    public void Add(User user) => _context.Users.Add(user);
}

Kluczowe cechy:

• Wyraźny podział logiki biznesowej i warstw infrastrukturalnych
• Możliwość łatwego wdrożenia atrap (mock) do testów jednostkowych
• Modułowość i skalowalność w miarę rozwoju systemu

Pytania z podstępem.

Czy Repozytorium musi znać strukturę bazy danych?

Nie. Repozytorium powinno operować na obiektach z zakresu tematycznego i ukrywać szczegóły przechowywania. Oddzielna Warstwa Dostępu do Danych zajmuje się mapowaniem na schemę bazy danych.

Czy można mieszać logikę biznesową wewnątrz klasy repozytorium?

Nie. Narusza to zasadę rozdzielenia trosk: Repozytorium odpowiada tylko za pobieranie/zapisywanie danych. Logika biznesowa powinna być przeniesiona do serwisów/obiektów domenowych.

Repozytorium a DAO — czy to to samo?

Niezupełnie. DAO jest ortogonalne do wzorca Repozytorium, działa na poziomie tabel i rekordów, podczas gdy Repozytorium działa z obiektami logiki biznesowej. Repozytorium abstrahuje kolekcje biznesowych bytów, DAO jest bliższe infrastrukturze.