1с программирование. Лекция 1 Вводное занятие. Инструктаж План разработка прикладных решений Общие сведения о системе
 Скачать 2.39 Mb.
|
|
Лекция №18 Основные понятия бухгалтерского учета План: особенности использования ссылочных данных кеш объектов особенности использования ссылочных данных В этом разделе мы поговорим об особенностях использования ссылочных данных, так как, используя доступ к этим данным с помощью запросов, мы можем значительно повысить скорость проведения документа и оптимизировать этот процесс. Термином «ссылочные данные» мы будем обозначать данные, хранящиеся в базе данных, доступ к которым возможен при помощи объектов встроенного языка вида Ссылка: СправочникСсылка.<имя>, ДокументСсылка.<имя> и т. д. Для того чтобы дальнейшее изложение было понятнее, мы построим объяснение на примере получения ссылки на вид номенклатуры при проведении документа ОказаниеУслуги. Не все данные, хранящиеся в базе данных, являются ссылочными. Это связано с тем, что в модели данных «1С:Предприятия» существует деление на данные, представляющие объектные сущности (справочники, планы счетов, документы и т. д.), и данные, представляющие необъектные сущности (регистры сведений, регистры накопления и т. д.). С точки зрения платформы некоторая совокупность объектных данных определяется не только значениями своих полей, но и самим фактом своего существования. Другими словами, удалив из базы некоторую совокупность объектных данных, мы не сможем вернуть систему в то же состояние, которое было до удаления. Даже если мы заново создадим ту же самую совокупность объектных данных с теми же самыми значениями полей, с точки зрения системы это будет ДРУГАЯ совокупность объектных данных. Каждую такую совокупность объектных данных, уникальную с точки зрения системы, называют объектом базы данных. Для того чтобы система могла отличить один объект базы данных от другого, каждый объект базы данных (совокупность объектных данных) имеет внутренний идентификатор. Различные объекты базы данных всегда будут иметь разные внутренние идентификаторы. Этот идентификатор хранится вместе с остальными данными объекта в специальном поле Ссылка. Необъектные данные хранятся в виде записей и с точки зрения системы определяются исключительно значениями своих полей. Таким образом, удалив некоторую запись и записав после этого новую, с точно такими же значениями всех полей, мы получим то же самое состояние базы данных, которое было до удаления. Таким образом, поскольку мы можем однозначно указать на каждый объект базы данных, у нас появляется возможность хранить такой указатель в полях других таблиц базы данных, выбирать его в поле ввода, указывать в параметрах запроса при поиске по ссылке и т. д. Во всех этих случаях как раз и будет использоваться объект встроенного языка вида Ссылка. Фактически этот объект хранит только внутренний идентификатор, находящийся в поле Ссылка. Например, если взять наш документ ОказаниеУслуги, то в поле, хранящем реквизит табличной части Номенклатура, на самом деле находится внутренний идентификатор, указывающий на элемент справочника Номенклатура (рис. 14.1).  Рис. 14.1. Ссылка на элемент справочника «Номенклатура» Когда в обработчике события ОбработкаПроведения документа ОказаниеУслуги мы присваиваем значение реквизита табличной части Номенклатура какой-либо переменной, мы имеем дело с объектом встроенного языка ДокументОбъект.ОказаниеУслуги. Этот объект содержит в себе значения всех реквизитов документа и реквизитов его табличных частей. Поэтому обращение (листинг 14.1) приводит к тому, что мы просто читаем данные, хранящиеся в оперативной памяти, в этом самом объекте встроенного языка (рис. 14.2). листинг 14.1. Обращение к реквизиту объекта Движение.Материал = ТекСтрокаПереченьНоменклатуры.Номенклатура;  Рис. 14.2. Чтение данных из оперативной памяти Однако когда мы обращаемся к виду номенклатуры как к реквизиту того элемента справочника, ссылка на который указана в табличной части документа (листинг 14.2), происходит буквально следующее (рис. 14.3). листинг 14.2. Обращение к реквизиту ссылки
 Рис. 14.3. Использование кеша объектов Поскольку в объекте ДокументОбъект.ОказаниеУслуги есть только ссылка на элемент справочника Номенклатура и больше никаких данных об этом элементе нет, платформа возьмет эту ссылку и обратится по ней в кеш объектов в надежде найти там данные того объекта, ссылка на который у нее есть. Если кеш объектов не будет иметь нужных данных, он обратится к базе данных с тем, чтобы прочитать все данные объекта, ссылкой на который он обладает. После того как все данные, хранящиеся в реквизитах нужного элемента справочника и в реквизитах его табличных частей, будут считаны в кеш объектов, кеш объектов вернет запрашиваемую ссылку, хранящуюся в реквизите ВидНоменклатуры справочника Номенклатура. Если же в алгоритме проведения требуется анализировать дополнительные реквизиты объектов, ссылки на которые содержатся в документе, а также использовать результаты расчета итогов регистров, следует использовать запросы для более быстрой выборки данных из базы данных. То же самое справедливо в отношении выполнения любых участков программы, критичных по производительности. Механизм запросов лучше «читает» информационную базу и может за один раз выбрать только те данные, которые необходимы. Поэтому, например, в типовых решениях вы практически не увидите использования объекта встроенного языка СправочникВыборка.<имя>. Вместо этого повсеместно используются запросы к базе данных. Вопросы: особенности использования ссылочных данных кеш объектов Лекция №19 Функционирование системы. План: Объекты Сервер и клиенты Компиляция общих модулей Объекты. Что такое объект в терминах «1С:Предприятия»? Этот вопрос зачастую ставит в тупик не только начинающих разработчиков, но и людей, имеющих определенный опыт разработки на платформе «1С:Предприятие». Основная трудность заключается в том, что всегда нужно ясно представлять себе, в каком контексте употребляется этот термин. Как правило, термин объект употребляется в одном из трех контекстов: конфигурация, база данных, встроенный язык. Говоря о конфигурации, термином объект конфигурации мы обозначаем некоторую совокупность описания данных и алгоритмов работы с этими данными. Например, в конфигурации может существовать объект Справочник Сотрудники. На основании каждого объекта конфигурации в базе данных создается информационная структура, в которой будут храниться данные. Так вот, когда мы говорим о базе данных, термином «объект» мы обозначаем всего лишь некий элемент такой информационной структуры. Характерной особенностью такого элемента является то, что на него (как на совокупность данных) существует ссылка, которая может являться значением какого-либо поля другой информационной структуры. Например, в базе данных существует справочник Сотрудники, в котором есть сотрудник Иванов. В этом случае элемент справочника, содержащий информацию о сотруднике Иванове, будет являться объектом базы данных. И если в документе ПриходнаяНакладная будет существовать реквизит ОтветственноеЛицо, то тип значения этого реквизита будет ссылкой на объект базы данных, то есть на элемент справочника, содержащий информацию об Иванове. Если же мы начинаем говорить о встроенном языке и о том, каким образом средствами встроенного языка работать со справочниками, то термином «объект» мы обозначаем тип данных, позволяющий получить доступ к данным и обладающий набором свойств и методов. Существует целый ряд объектов встроенного языка, позволяющих работать со справочниками (СправочникиМенеджер, СправочникМенеджер.<имя>, СправочникСсылка.<имя> и т. д.). Среди них есть один объект, который предоставляет доступ к объекту справочника в базе данных, – СправочникОбъект.<имя> (рис. 5.45).  Рис. 5.45. Объект конфигурации, объект базы данных, объекты встроенного языка Сервер и клиенты На предыдущем занятии мы создали одну процедуру для обработки нескольких событий и поместили ее в общий модуль РаботаСДокументами. В свойствах этого общего модуля мы устанавливали флажки Клиент и Сервер. Объясним подробнее, откуда в «1С:Предприятии» взялись вообще какие-то «клиенты» и «серверы». Система «1С:Предприятие» поддерживает два варианта работы системы: файловый и клиент-серверный.  Файловый вариант работы с информационной базой рассчитан на персональную работу одного пользователя или работу небольшого количества пользователей в локальной сети. В этом варианте все данные информационной базы (конфигурация, база данных, административная информация) располагаются в одном файле (рис. 5.46).Рис. 5.46. Файловый вариант работы  Основное назначение файлового варианта – быстро и легко установить систему и работать с ней. Например, чтобы что-то посмотреть или доработать дома на ноутбуке. В файловом варианте тоже можно вести реальную учетную работу, но при этом нужно понимать, что он не предоставляет абсолютно всех тех же возможностей по масштабируемости, защите данных, какие имеет клиент-серверный вариант. Поэтому, если вы самостоятельно ведете бухгалтерский учет или у вас небольшой коллектив сотрудников, и вам не требуется гарантированная защита данных от несанкционированного использования сотрудниками, и вы имеете относительно небольшой объем данных, можно работать в файловом варианте. В остальных же случаях нужно использовать клиент-серверный вариант.Клиент-серверный вариант предназначен для использования в рабочих группах или в масштабе предприятия. Он реализован на основе трехуровневой архитектуры «клиентсервер Клиент-серверный вариант работы – это основной вариант для работы в многопользовательской среде с большим объемом данных. Он предоставляет абсолютно все возможности по масштабируемости, администрированию и защите данных. Однако он требует значительных усилий по установке и администрированию. При этом физически серверная и клиентские части системы «1С:Предприятие» могут располагаться как на разных компьютерах, так и на одном. Главное, что пользователь не имеет непосредственного доступа к серверу баз данных, и это позволяет обеспечивать безопасность данных. А в файловом варианте база данных должна находиться на некотором общем сетевом ресурсе, доступном всем пользователям. Система «1С:Предприятие» изначально рассчитана на клиентсерверный вариант работы. Хотя сейчас вы разрабатываете свою учебную конфигурацию в файловом варианте работы, она будет работать и в клиент-серверном варианте без ваших дополнительных усилий. Прикладные решения разрабатываются один раз и одинаково работают, что в одном, что в другом варианте. То есть переход с одного варианта на другой не требует переделки конфигурации. Это достигается за счет того, что конфигурация разрабатывается всегда исходя из клиент-серверной архитектуры. В системе «1С:Предприятие» просто нет возможности разрабатывать ее по-другому. И в том случае, когда используется файловый вариант работы, система при исполнении прикладного решения просто «имитирует» наличие сервера на клиентском компьютере. Клиент-серверная архитектура разделяет всю работающую систему на три различные части, определенным образом взаимодействующие между собой, – клиент, сервер «1С:Предприятия» и сервер баз данных. Клиентское приложение – это программа, часть системы «1С:Предприятие». Основное ее назначение – организация пользовательского интерфейса, отображение данных с возможностью их изменения. Кроме этого, клиентское приложение может исполнять код на встроенном языке (то есть какие-то алгоритмы разработчика), но оперирует при этом лишь очень ограниченным пространством типов встроенного языка. Такой подход позволяет клиентскому приложению быть очень «легким», не требовать много ресурсов, «путешествовать» по Интернету и работать даже в среде веб-браузеров. Клиентское приложение взаимодействует с сервером «1С:Предприятия». Сервер «1С:Предприятия» – это тоже программа, часть системы «1С:Предприятие». Одна из основных задач этой программы – передавать запросы от клиентского приложения к серверу баз данных и возвращать обратно клиенту результаты этих запросов. Другая задача сервера – исполнение большинства алгоритмов на встроенном языке, подготовка данных для отображения форм, отчетов и т. д. То есть все сложные вычисления, требующие непосредственной работы с данными, исполняются именно на сервере. При этом на сервере доступно практически все пространство типов встроенного языка «1С:Предприятия» (за исключением, естественно, чисто интерфейсных типов, потому что у сервера нет никакой интерфейсной части, так как он общается не с пользователями, а только с другими программами: клиентским приложением и с сервером баз данных). Сервер баз данных – это тоже программа. Она уже не является частью системы «1С:Предприятие», это специализированная программа, поставляемая сторонними производителями. Ее основное назначение – это организация и ведение баз данных – структурированных организованных наборов данных, описывающих характеристики каких-либо физических или виртуальных систем. В настоящее время система «1С:Предприятие» может работать со следующими серверами баз данных: Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database. Компиляция общих модулей На предыдущем занятии мы создали одну процедуру для обработки нескольких событий и поместили ее в общий модуль РаботаСДокументами. У этого модуля, как и у всякого общего модуля конфигурации, существует набор свойств: Клиент (управляемое приложение), Сервер и Внешнее соединение. Значения этих свойств (истина/ложь) определяют, где будут скомпилированы экземпляры этих модулей. Расскажем подробнее о том, что происходит, когда мы устанавливаем те или иные флажки у общего модуля. Прежде всего, необходимо понимать, зачем необходима компиляция. Дело в том, что все, что мы разработали и написали в конфигурации, – пока только некая «заготовка». Платформа, когда мы запускаем ее в режиме 1С:Предприятие, превращает все это в программу, которую уже можно исполнить на компьютере, – компилирует. При этом, как мы уже сказали ранее, есть разные части системы, в которых исполняется код – сервер, клиентские приложения. Поэтому для общих модулей мы можем и должны в явном виде указать, где, на какой «стороне» они должны быть скомпилированы – на сервере или клиенте. Вопросы: Объекты Сервер и клиенты Компиляция общих модулей Лекция №20 Краткое описание понятий (объектов). План: Логическая связь объектов Создание новых объектов конфигурации Описание характеристик вариантов номенклатуры Логическая связь объектов Для реализации этого примера нам понадобятся три новых объекта конфигурации. Прежде всего, это План видов характеристик. Он будет хранить виды характеристик, которыми в принципе можно описывать материалы. Кроме этого, нам понадобится специальный справочник, подчиненный справочнику Номенклатура. Элементы этого справочника будут идентифицировать партии материалов с некоторым фиксированным набором значений характеристик. И третий объект – это регистр сведений, в котором собственно и будет храниться соответствие конкретных значений характеристик некоторому варианту материала (см. рис. 15.4).  Рис. 15.4. Логическая связь объектов В результате использования такой логической структуры объектов мы получим возможность описывать каждую поступающую партию материала любым количеством видов характеристик, поскольку это соответствие будет храниться в регистре сведений. И вместе с этим мы получим возможность вести учет в разрезе видов характеристик, добавив в регистры накопления еще одно измерение для хранения ссылки на элемент справочника, подчиненного справочнику Номенклатура (рис. 15.4). В результате для того, чтобы узнать остатки материалов, обладающих некоторым значением характеристики, достаточно будет выбрать из регистра сведений все элементы подчиненного справочника с этим значением характеристики и затем по ним и их владельцам получить остатки регистра накопления. Создание новых объектов конфигурации Как мы уже говорили, нам понадобится создать несколько новых объектов конфигурации: справочник ВариантыНоменклатуры, чтобы описывать партии материалов; справочник ДополнительныеСвойстваНоменклатуры, чтобы задавать значения видов характеристик, для которых нет подходящих типов в конфигурации; план видов характеристик СвойстваНоменклатуры, чтобы создавать виды характеристик; регистр сведений ЗначенияСвойствНоменклатуры, чтобы хранить значения видов характеристик для различных партий материалов. Сначала создадим объект конфигурации Справочник с именем ВариантыНоменклатуры и укажем, что он будет подчинен справочнику Номенклатура. Для этого на закладке Владельцы добавим справочник Номенклатура в список владельцев справочника ВариантыНоменклатуры. Затем создадим еще один объект конфигурации Справочник с именем ДополнительныеСвойстваНоменклатуры. После этого создадим объект конфигурации План видов характеристик с именем СвойстваНоменклатуры. Установим его свойство Тип значения характеристик. Для этого нажмем кнопку выбора  и зададим составной тип данных следующим образом (рис. 15.5):Число, длина 15, точность 3; Строка, длина 25; Дата; Булево; СправочникСсылка.ДополнительныеСвойстваНоменклатуры. Рис. 15.5. Определение составного типа данных для типа значения характеристик плана видов характеристик Затем справочнику ДополнительныеСвойстваНоменклатуры укажем владельца – план видов характеристик СвойстваНоменклатуры Описание характеристик вариантов номенклатуры В заключение для справочника ВариантыНоменклатуры опишем, где хранятся свойства вариантов номенклатуры и как получить значения этих свойств. Это описание платформа будет использовать автоматически при выполнении отчетов и при формировании различных динамических списков, в которых задействуются варианты номенклатуры. В контекстном меню справочника ВариантыНоменклатуры выберем команду Характеристики (рис. 15.10). Рис. 15.10. Переход к характеристикам справочника «ВариантыНоменклатуры» Откроется диалог описания характеристик. С помощью кнопки Добавить в командной панели добавим в него новую запись. В качестве источника характеристик выберем план видов характеристик СвойстваНоменклатуры. Платформа автоматически определит, что полем ключа будет являться поле Ссылка этого объекта конфигурации (рис. 15.11). Два оставшихся поля, Поле отбора видов и Значение отбора, оставим пустыми. В нашем случае эти поля не понадобятся. Перейдем к описанию того, где и как хранятся значения наших свойств. В качестве источника значений характеристик выберем регистр сведений ЗначенияСвойствНоменклатуры. Платформа автоматически определит, что в этом регистре полем объекта является измерение НаборСвойств, а полем вида – измерение ВидСвойства. Рис. 15.11. Описание источника видов характеристик Поэтому единственное, что нам останется указать самостоятельно, что значения свойств хранятся в ресурсе Значение. В результате описание характеристик для справочника ВариантыНоменклатуры будет выглядеть следующим образом (рис. 15.12). Рис. 15.12. Описание характеристик для справочника «ВариантыНоменклатуры» Вопросы: Логическая связь объектов Создание новых объектов конфигурации Описание характеристик вариантов номенклатуры |