Ответ.

Паттерн Repository инкапсулирует логику доступа к источнику данных (БД, API и т.п.), предоставляя слой абстракции между доменной логикой и механизмом хранения данных. Основная цель — скрыть детали реализации хранения и обеспечения работы с коллекцией объектов предметной области.

Преимущества:

• Облегчает тестирование за счет возможности подмены источника данных
• Способствует соблюдению принципа единой ответственности
• Упрощает миграцию БД, смену источника данных или кэширующих proxy

Пример кода на 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);
}

Ключевые особенности:

• Четкое разделение бизнес-логики и инфраструктурных слоев
• Возможность легко внедрять заглушки (mock) для юнит-тестов
• Модульность и масштабируемость по мере роста системы

Вопросы с подвохом.

Обязан ли Repository знать о структуре базы данных?

Нет. Repository должен оперировать объектами предметной области и скрывать детали хранения. Отдельный Data Access Layer занимается маппингом на схему БД.

Можно ли смешивать бизнес-логику внутри класса-репозитория?

Нет. Это нарушает Separation of Concerns: Repository отвечает только за получение/сохранение данных. Бизнес-логика должна быть вынесена в сервисы/доменные объекты.

Repository и DAO — это одно и то же?

Не совсем. DAO ортогонален паттерну Repository, работает на уровне таблиц и записей, тогда как Repository — с объектами бизнес-логики. Repository абстрагирует коллекции бизнес-сущностей, DAO ближе к инфраструктуре.