Архитектурный паттерн Repository в 1С: примеры применения и ошибки, которых стоит избегать

Проблема: код в 1С часто «растет хаотично» — бизнес-логика, доступ к данным и интерфейс смешиваются в одном модуле. Это приводит к дублированию запросов, сложной поддержке и высоким рискам при изменениях.
Решение: внедрение архитектурного паттерна Repository (репозиторий), который отделяет логику доступа к данным от прикладного кода и делает систему более гибкой, предсказуемой и тестируемой.

---

Что такое Repository и зачем он нужен

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

Главная идея: бизнес-код должен работать не с «таблицами» или «запросами», а с абстракциями — объектами доменной модели.
Например, чтобы получить список заказов, система обращается не к «РегистрНакопления.Продажи.Остатки()», а к OrderRepository.GetByPeriod(ДатаНачала, ДатаОкончания).

Такой подход позволяет:

• менять источник данных без переписывания логики (например, переход с SQL-регистра на HTTP-сервис);
• использовать единые методы выборки и фильтрации;
• покрывать код тестами;
• ускорить разработку типовых CRUD-операций.

---

Базовая структура Repository в 1С

Репозиторий можно реализовать в виде общего модуля или класса (в зависимости от архитектуры проекта).

Пример минимальной структуры:

// ОбщийМодуль.РепозиторийЗаказов (Server)
Процедура Инициализация()
    // подключение зависимостей, настройка кэша
КонецПроцедуры

Функция НайтиПоНомеру(Номер)
    Запрос = Новый Запрос;
    Запрос.Текст = "
        ВЫБРАТЬ
            Заказы.Ссылка КАК Ссылка,
            Заказы.Дата,
            Заказы.Контрагент
        ИЗ
            Документ.ЗаказПокупателя КАК Заказы
        ГДЕ
            Заказы.Номер = &Номер";
    Запрос.УстановитьПараметр("Номер", Номер);
    Результат = Запрос.Выполнить().Выбрать();
    Если Результат.Следующий() Тогда
        Возврат Результат.Ссылка;
    Иначе
        Возврат Неопределено;
    КонецЕсли;
КонецФункции

Такой модуль отвечает только за получение данных, без бизнес-логики.
Вся логика проверки, расчета скидок, проведения и обмена с внешними системами должна выноситься выше — в сервисы или доменные объекты.

---

Пример применения Repository в 1С-проекте

Сценарий

Компания внедряет систему управления заказами, интегрированную с интернет-магазином. До рефакторинга код выборки дублировался в десятках обработок и модулей.

Решение

Создали единый модуль OrderRepository, содержащий методы:
GetByNumber(), GetByCustomer(), GetActive(), Save(), Delete().

Результат

• Сократили количество запросов на 30 %.
• Упростили тестирование: при изменении структуры регистра или таблицы — меняется только репозиторий.
• Возможность подменять репозиторий на тестовый (mock) для unit-тестов.
• Сократили время внедрения новых типов заказов с 5 дней до 2.

---

Частые ошибки при реализации паттерна Repository

1. Перегрузка ответственности.
   Репозиторий не должен «знать» о бизнес-процессах. Только CRUD — Create, Read, Update, Delete.
2. Жесткая связка с платформой.
   Ошибка — встраивать специфичный код (например, прямые вызовы формы или интерфейсных событий). Repository — это слой данных, он должен быть платформенно-агностичен.
3. Игнорирование кеширования.
   Часто разработчики повторно выполняют тяжелые запросы в циклах. Правильный подход — использовать внутренний кэш на уровне репозитория.
4. Нарушение принципа SRP (Single Responsibility).
   Не нужно объединять несколько сущностей (например, заказы и оплату) в один модуль. Каждый репозиторий — для своей модели.
5. Отсутствие интерфейсов.
   Хорошая практика — создать интерфейс IOrderRepository, что позволит подменять реализацию (например, для тестов или внешнего сервиса).

---

Как внедрить Repository в существующий проект 1С

1. Инвентаризация.
   Определите, какие объекты чаще всего используются в запросах и где код дублируется.
2. Создайте шаблон.
   Разработайте общий модуль с типовыми методами GetByID, GetList, Save, Delete.
3. Постепенный переход.
   Не переписывайте всё сразу — рефакторьте по мере доработок.
4. Добавьте интерфейсный слой.
   Используйте интерфейсы для стандартизации работы с репозиториями.
5. Документируйте.
   Опишите принципы и примеры использования в Wiki или в комментариях к коду, чтобы команда следовала единым подходам.

---

Когда Repository не нужен

Паттерн избыточен, если:

• конфигурация маленькая и используется только один источник данных;
• нет требований к тестированию и масштабируемости;
• объекты не связаны логически (например, простая обработка выгрузки).

В таких случаях проще использовать обычные запросы. Repository оправдан в проектах со сложной доменной логикой и длительным жизненным циклом.

---

Репозиторий в 1С — это не просто модный термин из мира Java или .NET, а реальный инструмент промышленной разработки. Он помогает структурировать код, уменьшить дублирование и облегчить сопровождение крупных конфигураций.

Однако внедрять его стоит осознанно — с четким разграничением ответственности и контролем качества кода. В сочетании с принципами DDD, SOLID и Unit-тестированием Repository становится важным кирпичиком современной архитектуры 1С.