Поддержка работы с несколькими конфигурациями 1С при помощи паттерна «Стратегия» на примере C#

Интеграция программного обеспечения с 1С не всегда ограничивается работой только с одной информационной базой. Нередко возникает необходимость реализовать поддержку нескольких конфигураций или даже различных версий одной и той же конфигурации.

Если при работе хотя бы с двумя конфигурациями выполняются действия схожие между собой по содержанию, целесообразно прибегнуть к паттерну «Стратегия».

Паттерн «Стратегия» позволяет не просто определить некое семейство алгоритмов для решения некоторых задач. Его основное преимущество в том, что при его использовании эти алгоритмы становятся взаимозаменяемыми и их можно изменять независимо от тех объектов, которые их используют.

Паттерн «Стратегия» имеет три составляющих:

  • Strategy (Стратегия). Базовый класс для Concrete Strategy. Объявляет интерфейс общий для всех поддерживаемых алгоритмов. Класс Context использует этот интерфейс для вызова конкретного алгоритма, реализованного в классе Concrete Strategy;
  • Concrete Strategy (Конкретная стратегия). Реализует алгоритм использующий интерфейс, объявленный в классе Strategy;
  • Context (Контекст). Класс, который использует алгоритмы «Стратегии». Хранит ссылку на объект класса Strategy и конфигурируется объектом класса Concrete Strategy. Также может определять интерфейс позволяющий объекту Strategy получить доступ к данным контекста.

Для того чтобы рассмотреть работу паттерна «Стратегия» применительно к нескольким конфигурациям 1С обратимся к примерам из цикла статей посвящённых работе с 1С в C# (часть 1 и часть 2).

Суть этих примеров подробно изложена в указанных статьях. Поэтому не станем их здесь описывать и перейдём сразу к постановке задачи и её решению с помощью паттерна «Стратегия».

Допустим необходимо реализовать в программе поддержку одновременно двух версий одной и той же конфигурации. При этом более новая версия имеет API для работы и, следовательно, работать с ней предпочтительно с его помощью, а более старая нет и работа с ней возможна только через объектную модель.

В обоих случаях выполняются одинаковые по своей сути действия получения и добавления данных, но используемые алгоритмы существенно отличаются. Исключение составляет только подключение к 1С через COM-сервер.

Таким образом, реализация получения и добавления данных для каждой конкретной конфигурации может быть выделена в отдельную «конкретную стратегию». В свою очередь сигнатуры соответствующих методов и подключение к 1С можно вынести в базовый класс «стратегию». В качестве «контекста» выступает класс программы, который отвечает за работу с 1С. В данном конкретном примере «контекстом» будет служить класс формы приложения.

Создадим абстрактный класс, который будет базовым для будущих «конкретных стратегий».

 abstract class Strategy1C

Этот класс уже включает реализацию подключения к 1С и защищённое строковое поля для хранения пути к информационной базе.

Теперь необходимо реализовать «конкретные стратегии» для работы со старой и новой версиями конфигурации.

Класс для работы со старой версией.

Класс для работы с новой версией.

 class ConfNew : Strategy1C

После этого остаётся только доработать класс формы.

Добавим закрытое поле класса Strategy1C.

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

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

Изменение стратегии выполняется просто.

 Однако самые главные изменения связаны непосредственно с взаимодействием с обеими версиями конфигураций.

Например, раньше при добавлении данных требовалась проверка версии конфигурации и соответствующее ветвление алгоритма.

 Похожая ситуация имела место и при получении данных.

После применения паттерна «Состояние» работа с обеими версиями конфигурации выполняется полностью идентично и, что тоже не маловажно, более компактно.

Как при добавлении.

 Так и при получении данных.

 В результате использования паттерна «Состояние» удалось добиться целого ряда преимуществ.
  • Бизнес-логика, связанная с работой с 1С, теперь полностью отделена от объекта, который её использует. В данном примере от интерфейса пользователя. Алгоритмы, реализованные в классах «конкретных стратегиях» могут со временем изменяться, но изменения тех компонентов, которые их используют, при этом не потребуются;
  • Работа со всеми поддерживаемыми конфигурациями стала полностью унифицированной. Это упрощает не только написание кода, но и расширение возможностей программы. При добавлении новой конфигурации потребуется только реализовать «конкретную стратегию» для работы с ней и её инициализацию. Всё остальное изменять не нужно;
  • Вследствие предыдущих пунктов также значительно упрощается разработка самих объектов использующих данные из 1С и их модернизация. В частности, в том примере, который был рассмотрен в данной статье, первоначальный интерфейс пользователя на Windows Forms можно без особого труда заменить на более современный с использованием WPF.

К недостаткам использования данного паттерна можно отнести «традиционные» для большинства паттернов увеличение количества классов в приложении и усложнение его архитектуры. Однако, преимущества, которые даёт использование паттерна «Стратегия» применительно к работе с несколькими конфигурациями 1С их покрывают в более чем достаточной степени.

Список источников
  1. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приёмы объектно-ориентированного проектирования. Паттерны проектирования.
  2. Стрелец Coder. Работа с 1С в C#. Способ 1. Работа с объектной моделью 1С
  3. Стрелец Coder. Работа с 1С в C#. Способ 2. Работа с API конфигурации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector