Одной из важных особенностей модели разработки 1С:Предприятия является использование в качестве инструмента разработки прикладного решения объектов конфигурации ориентированных на отражение типовых сущностей предметной области. В 1С:Предприятии разработчик прикладного решения описывает структуру данных и их взаимосвязь не в терминах таблиц базы данных, а в терминах объектов конфигурации. При этом каждый создаваемый объект конфигурации относится к определенному виду, для которого в платформе определен некоторый набор стандартных полей и типовое поведение. Такая модель проектирования не только сокращает время разработки, но и, что особенно важно, позволяет стандартизировать структуру прикладных решений и соответственно существенно упростить освоение и поддержку конфигураций.
При такой модели разработки одним из наиболее ответственных этапов проектирования является выбор вида объекта конфигурации, который будет использоваться для отражения конкретной сущности предметной области. От правильно принятого решения зависит не только удобство разработки, и эффективность работы создаваемого прикладного решения, но и возможность его развития и адаптации к возможным изменениям состава решаемых задач. В большинстве случаев, выбор вида объекта конфигурации не представляет большой сложности, так как для каждого вида объекта конфигурации определено основное назначение и имеется достаточно примеров, как в методических материалах, так и в типовых конфигурациях. Однако, разумеется, состав видов объектов конфигурации предоставляемый платформой как любая классификация не может однозначно определять выбор подходящего объекта во всех случаях. Поэтому в спорных ситуациях, когда выбор вида объекта конфигурации не очевиден, нужно внимательно проанализировать все особенности устройства и поведения объектов соответствующего вида. Для этого рекомендуется познакомиться не только с документацией, но и с материалами диска ИТС.
Например, одним из типичных вопросов, возникающих в сложных случаях, является выбор между объектными и необъектными данными. Чаще всего это выбор между справочником и регистром сведений. Здесь рекомендуется, прежде всего, обратить внимание на природу данных предметной области. Если сами данные являются, по сути, перечнем уникальных объектов, то рекомендуется использовать объектные данные. Подробно особенности использования тех и других данных описаны в разделах "Особенности использования типов данных, предназначенных для манипулирования объектами базы данных" и "Особенности использования типов, предназначенных для манипулирования необъектными данными".
Однако следует учитывать, что выбор вида объекта конфигурации не может производиться для каждой сущности предметной области отдельно. Необходимо обязательно анализировать всю совокупность сущностей отражаемых в конфигурации на текущий момент, а также учитывать возможное включение новых сущностей в дальнейшем. Поэтому о правильности принятия решения можно говорить только с учетом состава задач решаемых при разработке конкретной конфигурации. Например, в одном прикладном решении состав сотрудников организации будет правильно отражать в справочнике, так как с точки зрения этой конфигурации сотрудник является объектом. Однако в другой конфигурации, содержащей более широкую функциональность (например, многофирменность), может быть принято решение в справочнике отражать такую сущность как физические лица, как более общее понятие. А информация о сотрудниках в этом случае может храниться в регистре сведений. Фактически регистр сведений будет отражать факт работы конкретного физического лица в конкретной организации, реализуя, таким образом, связь "многие ко многим". Но может быть принято решение в пользу хранения и в этом случае сотрудников в справочнике, фактически отражая в справочнике в качестве объектов не физическое лицо, а трудовой договор, в котором указывается физическое лицо и организация. В этом случае справочник будет не просто связывать физические лица и организации, а описывать объекты – трудовые договора, имеющие свойство уникальность в пространстве и времени.
Таким образом, при проектировании состава объектов конфигурации, разработчику очень важно четко представлять какую сущность предметной области будет отражать конкретный объект. Соответственно рекомендуется определять и имя объекта конфигурации так, чтобы оно максимально отражало описываемую сущность.
Важно учитывать, что объекты конфигурации того или иного вида описывают не просто таблицы базы данных с некоторым набором полей, а обеспечивают определенную логику работы с данными. Эта логика определяет и состав возможностей, автоматически предоставляемых разработчику, и набор ограничений, и параметры производительности тех или иных операций с данными.
Типичной ошибкой, например, является использование регистра сведений в качестве простой таблицы для записи некоторых данных. Регистр сведений предназначен для хранения сведений соответствующих определенным комбинациям значений измерений. Соответственно одним из основных его свойств является обеспечение уникальности записей по составу измерений и периоду (для периодического регистра). Поэтому при каждой записи регистр сведений выполняет в обязательном порядке удаление существующих записей с такой комбинацией значений измерений или проверку уникальности (в зависимости от способа записи). Если при этом выполняется добавление одиночных записей с помощью менеджера записи, то такая операция будет приводить к достаточно большим накладным расходам, особенно, если имеется большое количество измерений. Таким образом, если отражаемая сущность предметной области не подходит по своей природе под регистр сведений, то следует рассмотреть целесообразность использования регистра сведений (особенно с учетом предполагаемого объема хранимой информации).
Еще одним аспектом, который следует рассматривать при выборе вида объекта конфигурации, является необходимость учета технологических особенностей работы платформы, с данными, поддерживаемыми этим объектом. Состава прикладных объектов конфигурации должен максимально соответствовать реальному составу сущностей предметной области, однако, при его проектировании необходимо рассматривать и технологические вопросы. В некоторых случаях даже в правильно спроектированную структуру объектов необходимо внести коррективы, диктуемые технологическими особенностями. Например, если в составе информации об объекте необходимо хранить большие объемы бинарных данных (картинки, файлы и т.д.), то для этой цели рекомендуется заводить отдельные объекты метаданных (справочники или регистры сведений) связанные с данным объектом, чтобы исключить обязательное считывание больших объемов информации при считывании объекта.
Если речь идет о структурах данных, предполагающих хранение большого объема информации или интенсивное использование, то для оценки эффективности принятого решения, можно рекомендовать провести эксперименты, в которых, на объемах данных сопоставимых с реальными, сравнить производительность одних и тех же операций с разными вариантами структуры.
В качестве еще одной рекомендации, можно предложить учитывать в процессе проектирования возможное использование в данной конфигурации механизмов обмена данными. Хотя такая потребность не всегда определена заранее, но можно предположить, что она может возникнуть в ходе эксплуатации системы. Поэтому полезно при проектировании основных объектов конфигурации подумать о возможных вариантах обмена с точки зрения принимаемых решений по организации структуры данных. Например, следует учитывать, что табличная часть объекта является его неотъемлемой частью при всех операциях добавления, записи и удаления. Соответственно при организации распределенной системы обмен данными объекта будет происходить, включая все его табличные части. С другой стороны данные регистров и подчиненных справочников участвуют в обмене самостоятельно, что позволяет управлять их миграцией независимо от объектов, с которыми они связаны. Например, может передаваться элемент справочника, но не передаваться регистр сведений, хранящий связанную с ним информацию.