Из статьи вы узнаете, как организована работа с моделью данных на платформе 1С: Предприятие и почему выбрана именно эта модель.
Работа с данными – одна из важнейших составляющих функционирования бизнес-приложений. Это естественно, ведь любая программа для бизнеса создана для обработки данных. В этом состоит главное отличие 1С от программ, в которых данные играют второстепенную роль. Попробуем разобраться, почему же данные так важны для бизнеса.
В первую очередь данные крайне важны по той причине, что описывают непосредственно предметную область: какие сущности функционируют в бизнесе, каким образом они взаимодействуют между собой. С помощью данных легко описать задачу, которую требуется решить. Разрабатывая программу, специалисты принимают в расчет не все данные, а лишь те, которые оказывают непосредственное влияние на решение поставленной задачи. Разберем на примере. Если мы подбираем специалиста из множества претендентов, приславших резюме, нас в первую очередь будет интересовать его образование, опыт работы и сформированные навыки, а не размер его одежды или обуви. Однако, если нужно автоматизировать учет спецодежды для работников, эта функция не помешает. Этот пример показывает, что число данных безгранично и искусство разработчика состоит в том, чтобы определить приоритетную модель данных.
И, несмотря на то, что в бизнес-приложениях важны и процессы и программистам хотелось бы возложить на них большее количество функций, все равно данные занимают главенствующее положение. По этой причине основная модель приложений построена на отражении данных.
Что мы понимаем под данными? В это понятие включается не только данные в традиционном понимании, но и данные, сопровождающие процессы. Таким образом, посредством модели данных выражаются процессы.
Парадигмы работы с данными
В основе работы с данными лежит классическая реляционная модель, то есть данные описаны в виде реляционных таблиц, хранятся они в реляционных DBMS. Несмотря на то что такая модель существует уже давно, на данный момент она достаточно актуальна.
В объектной парадигме данные представлены как объекты языка, место их хранения – база данных. Если данные хранятся в реляционной базе, то возможности моделирования определяет DBMS, если место хранения – объектная база, то используется ORM.
Среди методик, которые менее популярны у разработчиков, можно выделить подход, который основывается на слабоструктурированных данных.
Разработка платформы 1С: Предприятие основывается на оригинальном подходе, который неофициально называется «модель типов прикладных объектов». В чем заключается суть данного подхода? Разработчик имеет в своем распоряжении определенный набор прикладных объектов, который предлагает ему платформа на выбор. Каждый из этих объектов предназначается для того, чтобы отразить в модели будущего приложения сущности, характерные для данной предметной области. Разработчик, получив задачу, определяет, какие типы объектов ему необходимо выбрать для корректного описания предметной области. С помощью этих объектов будут описываться модели данных.
Типы прикладных объектов
Тип прикладных объектов – это своеобразный шаблон, изначально заложенный в платформу. Именно на тип прикладных объектов опирается специалист при работе с сущностью предметной области.
Используются типы прикладных объектов на стадии разработки системы (в design-time) и во время ее функционирования (в run-time). На стадии разработки тип прикладных объектов проявляется в метаданных и классах в виде мета-модели, используется в программной модели для манипулирования данными. В run-time тип прикладных объектов – это действия системы, отражающие работу системы с объектами данного типа.
Типы прикладных объектов в 1С:
- регистры накопления;
- справочники;
- документы.
Справочники используются для хранения и отражения информации, которая в системе представлена как условно постоянная, к примеру, списки поставщиков, ключевых клиентов, товаров.
В документах находится информация о событиях из предметной области (продажи, поставки, переводы денежных средств и др.). Имя документ получает преимущественно по названию печатных форм, к примеру, «платежное поручение», «приказ об увольнении» и так далее.
Функция регистров заключается в отражении системы учета, сформированной в приложении. К примеру, это может быть учет хранения остатков товара на складе или денежных средств на счетах компании.
Рассмотрим подробно, какие возможности предоставляют описанные выше типы прикладных объектов.
В первую очередь повторим, что тип прикладного объекта служит для описания модели данных и их отображении на реляционной модели хранения. И это лишь часть функциональных возможностей типа прикладного объекта.
В справочник, к примеру, заложены стандартные реквизиты полей (код, наименование, ссылка-идентификатор). В справочнике можно описать произвольные реквизиты или поля, а также связанные между собой сущности, которые представлены как табличные части.
В документ встроен реквизит Дата, в нем находят отражение события и их временное положение относительно других событий. В признаке «Проведен» находится информация о том, существует ли данный документ в системе отчета или на данный момент является черновиком.
В регистре накопления все поля разделены на три группы: реквизиты, ресурсы и измерения. В измерении описывается система координат для модели учета (склад, товар), в ресурсах – актуальные показатели (цена, количество), в реквизитах - дополнительные поля, которые никак не влияют на модель учета, но комментируют записи движений.
Почему не таблицы?
У многих может возникнуть вопрос: зачем пользоваться прикладными объектами, не проще ли оперировать, например, таблицами или (самый простой вариант) непосредственно сущностями?
Это резонный вопрос. Дадим на него развернутый ответ. Таблицы имеют массу достоинств, так как близки к реляционной модели, и к простейшему моделированию, а разработчик не ограничен в выборе заложенных типов. Вместе с тем таблицы лишены тех преимуществ, которые предоставляет подход, выбранный разработчиками 1С.
Главное достоинство этого подхода в том, что в платформе уже заложена информация о выбранных объектах и система знает, какие операции необходимо с ней провести. Основываясь на этих знаниях и умениях, система способна обеспечить автоматическую работу тех механизмов (а их больше десятка), которые прямо или косвенно взаимодействуют с объектами. Таким образом получается, что задача разработчика заключается в том, чтобы выбрать правильный тип объекта и описать конкретный объект. Система в зависимости от типа и описания конкретного объекта самостоятельно наделяет его набором необходимых механизмов и функций. Это становится возможным благодаря тому, что на уровне типа определенного объекта заложена семантика данного типа. Модель метаданных дает возможность уточнить значение объекта посредством свойств и специальных моделей, которые описывают разные стороны функционирования.
Основные из них:
- построение структур данных, служащих для хранения, а также их автоматическую трансформацию в случае изменения модели;
- отбор классов в объектной модели для операций с данными, к примеру, поиска, чтения и др.;
- механизм для объектно-реляционного преобразования;
- набор основных операций для обработки данных. К примеру, для документов такой процедурой будет автоматическая нумерация, для регистров – получение расчета итогов или количество остатков товара на складе на определенный момент времени;
- определение прав в системе, то есть, если система будет знакома с функциями объекта, соответственно, она будет знать, какие права будут на данный момент актуальны для него;
- визуализация. Опять же благодаря тому, что система знакома с назначением объекта и его ролью, она автоматически создает команды в интерфейсе приложения, которые обеспечивают быстрый доступ ко всем объектам данного типа. Также в автоматическом режиме создаются формы для редактирования или просмотра и команды для осуществления различных операций с объектами;
- обмен данными. В систему заложена семантика данных, на их основе система создает типовой механизм, служащий для обмена отредактированными данными. Причем обмен данными может осуществляться не только среди родственных приложений, но и между приложениями, написанными на 1С: Предприятии или на любой другой технологии;
- блокировки (транзакционные и объектные). Для того чтобы построить правильную и корректную систему блокировки, необходимо знать, для чего нужны данные и как они взаимодействуют между собой;
- механизм характеристик. Характеристика – это дополнительное поле, которое определяется пользователем;
- автоматическое предоставление REST-интерфейса (по стандарту OData);
- загрузка или выгрузка данных в XML, JSON;
- автоматическое функционирование различных механизмов , к примеру, поиск, доступ к данным и другие.
На схеме изображены основные механизмы, функционирующие на базе прикладных объектов.
Преимущество модели типов прикладных объектов
Типы прикладных объектов некоторым образом связаны с аспектно-прикладным подходом. Этот вывод можно сделать на основе того, что перечисленные выше возможности – это предопределенные объекты, в которых, в свою очередь, отражены различные типы прикладных объектов. Определенный набор свойств метаданных осуществляет параметризацию. Разработчик выбирает значение свойства, тем самым параметризируя шаблон определенного типа объекта и конкретизируя действия объекта в каждом отдельно взятом случае. К примеру, разработчик определяет тип нумерации документа, система же автоматически будет организовывать и контролировать выдачу номеров с заданной разработчиком периодичностью.
Зная тип прикладного объекта без труда можно определить семантику и сущностей, и их связей. К примеру, между регистрами и документами в системе существует связь, посредством которой в модели учета отражаются события из предметной области. Разработчик определяет эту связь и без труда получает функцию, которая будет показывать и документ, и все связанные с этим документом записи в регистре.
Стоит упомянуть и предметноориентированных аспектах. К примеру, в справочнике для включения поддержки иерархии достаточно одним кликом мышки поставить флажок. Причем поддержка иерархических справочников будет осуществляться на всех уровнях: пользовательском интерфейсе, объектной модели, отчетах. Пример такого свойства справочника, как «иерархический справочник» приведен на рисунке ниже.
В документах таким же свойством обладают журналы, которые объединяют сразу несколько типов документов, нумерация страниц по всему документу.
В регистрах необходимым свойством является автоматическое хранение подсчитанных итогов, а также созданные виртуальные таблицы, предоставляющие доступ к итогам по различным заданным параметрам и с учетом указанной периодичности.
Как можно заметить в типах прикладных объектов уже находятся все необходимые механизмы бизнес-приложений, которые характерны для определенной категории данных какой-либо предметной области.
То есть типы прикладных объектов можно сравнить с деталями конструктора. Подобно тому, как ребенок собирает игрушечный домик, разработчик собирает приложение, используя различные типы прикладных объектов. Причем, каждая «деталь» в конструкторе разработчика имеет свое предназначение, ее ни с чем не спутаешь.
На представленной выше схеме можно увидеть, что справочники различных типов (товары, продукты, валюта, сотрудник и т.д) строятся на одном и том же типе прикладного объекта – Справочник. На основе типа «Документ» образуются документы «Заказ на производство», «Счет», «Заказ на покупку» и множество других документов.
Нельзя не отметить методологическую ценность этого подхода, которая заключается в том, что разработчикам легко понять сущность приложения. Это значительно упрощает процесс общение друг с другом. Даже если разработчику придется работать с незнакомым проектом, он увидит знакомые понятия и без труда сможет понять, какую роль они играют в системе. К примеру, определить сущность любого приложения можно, посмотрев на состав регистров, именно он отражает предназначение приложения. Понять любою структуру таблиц или классов, созданных посредством универсальных инструментов, для специалиста не составит труда.
Не мене важным является и то, что такой универсальный подход сближает разработчика с заказчиком. Типы прикладных объектов достаточно быстро становятся понятны и людям, далеким от программирования, поэтому обсуждать приложения, написанные с помощью этого метода и разработчикам, и аналитикам, и заказчикам можно на понятном для каждого из них языке. Сейчас достаточно часто встречаются заказчики, которые ставят задачи разработчикам 1с, используя термины типов прикладных объектов, причем основами программирования заказчики чаще всего не владеют.
Еще одним преимуществом описанного подхода является то, что он служит толчком для развития системы. Развитие обеспечивается с помощью новых механизмов, которые быстро включаются в работу с уже существующими объектами, причем разработчики не всегда прикладывают максимум усилий для их адаптации в системе. К примеру, недавно был создан механизм хранения истории данных. Система уже знакома с семантикой данных, поэтому разработчику нужно всего лишь установить флажок, который обозначит, что нужно хранение данных, платформа же сама организует и хранение истории, и визуализацию – демонстрацию пользователю всех изменений данных в форме отчетов различных видов. К примеру, после разработки и внедрения механизма стандартного REST-интерфейса, он появился сразу во всех приложениях. Для этого программистам не пришлось ничего разрабатывать самим или вносить свои изменения в созданный продукт, пытаясь адаптировать его под свои нужды.
Почему же не пользоваться одновременно и типами прикладных объектов, и таблицами? Попробуем выяснить.
Конечно, на первый взгляд идея неплохая, поскольку сразу же закрылись бы неодназначные моменты, например, не всегда предметная область правильно ложится в подготовленный для этого набор типов. В этом случае простым было бы решение организовать работу с помощью таблиц. Но как быть с механизмами, которые привыкли работать с типами прикладных объектов и не понимают, что делать с таблицами и как правильно трактовать семантику данных.
Опыт работы с таблицами в 1С все же есть, хоть и небольшой. С помощью таблиц описываются внешние источники (без указания предметной области). Системе приходится работать универсальным способом, однако часть функционала не поддерживается.
Разработчики стараются воздерживаться от использования таблиц, чтобы сохранить чистоту модели и возможность беспрепятственно создавать новую функциональность с опорой на знание семантики необходимых данных. В случае нехватки каких-либо возможностей в первую очередь будет рассматриваться вопрос о развитии состава типов прикладных объектов. Однако на данный момент это достаточно спорный вопрос, открывать который нет смысла.
Таким образом можно сделать вывод, что типы прикладных объектов обеспечивают и возможности, представленные платформой 1С в готовом виде, и высокий уровень абстракции, который крайне необходим разработчикам. Это главное отличие платформы 1С: Предприятие от других подобных платформ и ее главное преимущество, обеспечивающее быструю и универсальную разработку любых бизнес-приложений.