Содержание к диссертации
Введение
1 Построение информационной компоненты САПР РЭА 11
1.1 Структура информационной компоненты САПР РЭА 19
1.2 Информационное обеспечение интегрированных САПР 26
1.3 Проектные решения схемотехнических САПР 38
1.4 Выводы 40
2 Архитектура архива проектных решений схемотехнических САПР 41
2.1 Методы построенияархива проектных решений 41
2.2 Построение АПР на основе систем электронного документооборота 48
2.3 Требования к реализации вэб-ориентированного АПР 54
2.4 Архитектура web-ориентированного АПР 57
2.5. Выводы 62
3 Модели данных для архива проектных решений 64
3.1 Семантическая модель данных для иерархии схемных компонентов 65
3.2Физическая модель данных для схемных компонентов 70
3.3 Семантическая модель данных для проектных решений 78
3.4. Объектно-ориентированная модель данных АПР 81
3.5 Выводы 83
4 Реализация web-ориентированного архива проектных решений 85
4.1 Выбор инструментальных средств для разработки АПР 85
4.2. Структура проекта ASP.NETMVC 5 88
4.3. Структура таблиц АПР ArchiveDB 89
4.4. Создание Web-приложения АПР ArchiveDBв среде ASP.NETMVC 101
4.5. Пример применения АПР ArchiveDB. 107
Заключение 110
Список сокращений и условных обозначений 112
Список литературы 113
- Информационное обеспечение интегрированных САПР
- Проектные решения схемотехнических САПР
- Построение АПР на основе систем электронного документооборота
- Создание Web-приложения АПР ArchiveDBв среде ASP.NETMVC
Введение к работе
Актуальность исследования
Современные технологии проектирования радиоэлектронной аппаратуры
(РЭА) базируются на сквозном применении систем автоматизированного
проектирования (САПР) на всех стадиях разработки, начиная от этапа
схемотехнического проектирования и заканчивая этапом технологической
подготовки производства. Особенностью использования САПР в данной
области является возможность получения проектного решения отдельного
узла или блока РЭА полностью в электронной форме. Совокупность файлов
проектного решения полностью описывает состав, структуру и параметры
проектируемой схемы и позволяет повторно воспроизвести моделирование
устройства в САПР. Таким образом, полученные проектные решения
возможно использовать в качестве базовых в новых разработках и при
модернизации уже существующих электронных блоков. Для систематизации и
хранения поученных результатов в сети Интернет необходим перенос
информационного фонда схемотехнических САПР на платформу баз данных
и разработка вэб-ориентированных версий специализированных СУБД.
Основой для построения информационной компоненты вэб-ориентированных
схемотехнических САПР может служить архив проектных решений (АПР),
содержащий все необходимые данные для повторного моделирования блока
РЭА и его модернизации. Следует отметить, что АПР может быть дополнен
проектными документами, формируемыми инженером-разработчиком во
внешних приложениях (Word, Excel, Acrobat и др.). Примерами таких
документов могут служить: техническое задание, пояснительная записка,
технические условия и т.д. Рассмотрим более подробно проблемы,
возникающие при создании архива проектных решений для
схемотехнических САПР.
В области теории и применения систем автоматизированного
проектирования в настоящее время развиваются два направления. Первое
направление связано с разработкой нового поколения вэб-ориентированных
САПР с распределенной архитектурой, включающей обрабатывающее ядро,
размещенное на корпоративном вэб-сервере САПР, и интерфейсную
подсистему на клиентской рабочей станции, использующую в качестве
основного средства взаимодействия с пользователем интернет-браузер.
Второе перспективное направление базируется на переносе САПР,
построенных по традиционной архитектуре, в “облако” и реализацию
взаимодействия пользователя с системой на основе облачных технологий.
Общей задачей в рамках данных направлений является перевод
информационной компоненты САПР на платформу баз данных с учетом требований, предъявляемых к взаимодействию пользователя с системой в Интернет-среде.
Для решения поставленной задачи необходимо:
провести анализ традиционных методов организации информационной компоненты САПР; разработать новые методы и модели для размещения проектных данных в универсальных СУБД; создать программную среду для управления процессом централизованного хранения и удаленного доступа к информационным ресурсам вэб-ориентированных схемотехнических САПР.
Основой новой структуры информационной компоненты вэб-
ориентированных схемотехнических САПР может служить архив проектных решений, размещаемый на вэб-сервере Интернет-ресурсов. Наличие такого архива в составе САПР позволяет решать задачи систематизации, хранения и повторного использования проектных решений при проектировании новых радиоэлектронных изделий.
Существующие способы организации информационного обеспечения (ИО) схемотехнических САПР не отвечают современным требованиям к хранению и защищенности проектных данных, а именно:
обеспечение коллективного доступа к файлам электронного проекта и возможность удаленной работы над общим проектом в Интернете;
хранение, поиск и модификация проектных данных, размещенных на вэб-сервере Интернет-ресурсов САПР;
обязательная защищенность проектных данных и разграничение прав доступа к проектам на основе процедуры авторизации пользователей;
возможность дополнительной обработки и выпуска конструкторской документации на основе хранящихся файлов электронного проекта;
фиксирование событий, связанных с доступом к проектным данным и операциям по их изменению;
наличие универсального открытого интерфейса для подключения АПР к различным типам схемотехнических САПР.
обеспечение резервного копирования текущего состояния АПР.
Сформулированные выше требования необходимо учитывать на всех
этапах построения АПР, начиная от этапа формирования семантических моделей данных и заканчивая проектированием архитектуры АПР.
Актуальность темы определяется необходимостью решения проблемы разработки научных основ построения средств САПР, а именно создания архива проектных решений, обеспечивающего хранение, поиск и модификацию электронных проектов в области автоматизированного проектирования радиоэлектронной аппаратуры на основе технологий баз данных для повышения эффективности использования вэб-ориентированных схемотехнических САПР. С учетом сказанного разработка архива проектных решений является актуальной задачей, имеющей большое научное и практическое значение для разработки современных высокопроизводительных САПР РЭА.
Предметом исследования является информационная компонента вэб-
ориентированных систем схемотехнического проектирования,
ориентированная на применение в сети Интернет и построенная на основе использования универсальных СУБД.
Объектом исследования диссертационной работы являются методы формирования и хранения электронных проектов узлов и блоков РЭА, полученных в процессе автоматизированного проектирования на основе архива проектных решений.
Цели и задачи исследования
Цель работы - исследование и разработка информационной компоненты схемотехнических САПР для организации архива проектных решений, ориентированного на удаленный доступ к централизованному хранилищу проектных данных на вэб-серверах в сети Интернет.
Основная задача диссертации - повышение эффективности коллективного использования схемотехнических САПР на основе применения вэб-ориентированного архива проектных решений.
Для достижения поставленной цели исследования необходимо решить следующие подзадачи:
-
Проанализировать структуру информационной компоненты современных схемотехнических САПР и выявить необходимый набор файлов для формирования электронного проекта разрабатываемого радиоэлектронного изделия. Выработать требования к размещению проектных данных в сети Интернет на основе технологий баз данных.
-
Выполнить сравнение методов построения информационной компоненты вэб-ориентированных программных комплексов и на их основе спроектировать архитектуру архива проектных решений для радиоэлектронных изделий.
-
Построить семантические модели данных для рассматриваемой предметной области и реализовать полученную схему данных в среде универсальной клиент-серверной СУБД.
-
Разработать управляющую подсистему архива проектных решений с вэб-интерфейсом, дающую возможность организации коллективной работы над электронными проектами в сети Интернет и позволяющую повысить эффективность применения систем схемотехнического проектирования.
Основные методы исследования: В ходе выполнения диссертации были использованы семантические модели предметной области, математические модели схемных компонентов, теория построения САПР, интернет-технологии, теоретические основы построения реляционных, объектно-ориентированных и документно-ориентированных баз данных. Экспериментальная часть диссертации (разработка информационного и программного обеспечения архива проектных решений) выполнялись на основе СУБД MSSQL-Server и MS Visual Studio 2013.
Достоверность научных результатов
Подтверждается основными положениями теории математического
моделирования непрерывных объектов, теории построения САПР,
корректностью применяемого математических методов, и практическими испытаниями вэб-ориентированного архива проектных решений ArchiveDB, построенного в среде СУБД MS SQL-Server и MS Visual Studio 2013.
Новые научные результаты
1. Разработана универсальная открытая архитектура
информационной компоненты схемотехнических САПР, отличающаяся от известных информационных подсистем САПР наличием архива проектных решений и включающая хранилище проектных данных и отношения реляционной СУБД. Предложена структура управляющего серверного приложения, функционирующего на вэб-сервере интернет-ресурсов САПР.
-
Разработана новая расширенная семантическая модель “сущность-связь” для электронных проектных документов, входящих в состав проектного решения, основанная на супертипах и подтипах сущностей, учитывающая блочно-подчиненную структуру проектов в схемотехнических САПР, математические зависимости между объектами и наличие нескольких уровней доступа к проектным данным.
-
Построена платформенно-независмая объектно-ориентированная даталогическая модель данных АПР, отличающаяся от известных использованием механизма проектных процедур для реализации математических зависимостей между параметрами проектируемой схемы, что позволяет дополнительно в рамках АПР выпускать проектную документацию в соответствии с требованиями ГОСТ. Разработанная модель доступна для реализации в большинстве современных инструментальных сред программирования.
-
Предложена новая методика построения информационной компоненты схемотехнических САПР, обеспечивающая хранение и повторное использование проектных решений в сети Интернет.
Основные положения, выносимые на защиту
1. Архитектура информационной компоненты архива проектных решений
для вэб-ориентированных схемотехнических САПР.
2. Расширенная семантическая модель «сущность-связь» предметной
области для АПР.
3. Платформенно-независмая объектно-ориентированная даталогическая
модель данных АПР.
4. Методика построения информационной компоненты вэб-
ориентированных схемотехнических САПР на основе интернет-технологий и
технологий баз данных.
Практическая ценность
1. Разработанная универсальная открытая архитектура архива проектных решений может выступать в качестве ядра для переноса ИО САПР в сеть интернет.
-
Расширенная иерархическая ER-модель “сущность-связь” для АПР может быть использована при построении семантических моделей сложных технических объектов в смежных областях.
-
Применение реализованной в рамках диссертации системы ArchiveDB в инженерной практике дает возможность хранения на вэб-сервере полных проектных решений и использовании их в новых разработках РЭА, что значительно повышает эффективность использования САПР.
-
Разработанное программное и информационное обеспечение АПР базируется на инвариантном вэб-ориентированном ядре, которое может быть использовано в различных прикладных системах в сети интернет.
Реализация и внедрение результатов
На основе полученных научных и практических результатов создана система ArchiveDB для схемотехнических САПР. Применение системы ArchiveDB в повседневной практике автоматизированного проектирования РЭА позволяет решить следующие задачи: долговременное архивное хранение проектов; внесение исправлений и дополнений в проектные решения; использование готовых проектных решений в новых разработках; дополнительную обработку результатов проектирования с целью выпуска проектной документации; может служить основой для организации удаленного доступа к проектной документации со стороны распределенного коллектива разработчиков РЭА.
Теоретические и практические результаты диссертационной работы использовались в НИР САПР 78 по теме: «Исследование и разработка пакета прикладных программ обработки расчета и обоснования стоимости комплектующих изделий» в 2015г.
Результаты диссертации внедрены в учебную практику кафедры САПР СПб ГЭТУ «ЛЭТИ» в рамках курса «Информационное обеспечение САПР» при подготовке магистров по направлению «Информатика и вычислительная техника», что подтверждается актом о внедрении.
Апробация работы
Основные положения диссертации докладывались и обсуждались на следующих конференциях:
международная научно-техническая конференция 2015г. «Информационные технологии и математическое моделирование систем». - М.: ЦИТП РАН.
XV-ая международная конференция по мягким вычислениям и измерениям (SCM 2012). - СПб.
XVI-ая международная конференция по мягким вычислениям и измерениям (SCM 2013). - СПб.
XVII-ая международная конференция по мягким вычислениям и измерениям (SCM 2014). - СПб.
63, 64, 65-ая научно-технические конференции профессорско-преподавательского состава СПбСГЭТУ.
Публикации
Основное теоретические и практические результаты диссертации опубликованы в 6 печатных работах, в числе которых 2 статьи в ведущих рецензируемых изданиях, рекомендованных в действующем перечне, 4 работы - в материалах международных конференций.
Структура и объем диссертации
Диссертационная работа состоит из введения, четырех глав, заключения и списка литературы, включающего 63 наименований. Диссертация изложена на 145 страницах, содержит 16 рисунков и 3 таблицы.
Информационное обеспечение интегрированных САПР
Для каждого типа интерфейса существуют адекватные диалоговые средства — речевые, символьные, графические и смешанные.
Под диалогом в настоящей работе будем понимать процесс оперативного обмена сообщениями между человеком и ЭВМ (партнерами), обеспечивающий решение задач схемотехнического проектирования РЭА. Шаг диалога — это часть диалога, включающая: вывод сообщения из ЭВМ, анализ пользователем САПР полученного от ЭВМ сообщения; ввод сообщения в ЭВМ; обработка системой схемотехнического проектирования введенного пользователем сообщения. Диалоговое сообщение — это символьная или графическая информация, которой партнеры обмениваются на каждом шаге диалога. Между отдельными частями сообщений имеются функциональные связи, составляющие структуру диалоговых сообщений. Под диалоговым сеансом понимается выполнение пользователем набора проектных процедур и/или операций, обеспечивающих решение проектной задачи в среде САПР.
Важно определить место диалоговых ССП в процессе автоматизированного проектирования и изготовления РЭА. Разработка РЭА включает этапы структурного, функционально-логического, схемотехнического и конструкторского проектирования. Все этапы сквозного процесса проектирования РЭА (от ввода первичного описания объекта до выпуска документации для его изготовления) должны выполняться винтегрированной САПР, которая объединяет разнородные подсистемы автоматизации различных этапов проектирования РЭА. Результатом функционирования систем структурного и функционально логического проектирования является функциональная спецификация схемы, или входные параметры ССП, FTЗ={fi}, i= = 1, п, определяющие техническое задание (ТЗ) на схемотехническое проектирование. К входным параметрам FTЗ относятся параметры окружающей среды (температура, влажность, радиация и т. д.), качественные показатели схемы (функциональные зависимости — частотные, переходные, статические и т. д., предельные значения токов и напряжений в характерных точках схемы, пороговые параметры, быстродействие, помехоустойчивость и т. д.), заданные в форме требований, ограничений, условий. При автономном использовании ССП входные параметры FTЗ задает инженер-схемотехник. Выходные параметры ССП АТД={аj }, j=1, т, или атрибутивная спецификация схемы, служат основой конструкторского проектирования. Они являются исходными для решения задач коммутационно-монтажного проектирования и задач анализа вариантов конструкций (включая анализ тепловых режимов и помехоустойчивости). Выходные параметры Атд оформляются в виде технической документации, например, схем устройств ЭВМ, схем ИС и фрагментов БИС, содержащей как количественное, так и качественное описание требований, ограничений и условий выполнения этапа конструирования РЭА.
Выходные параметры ССП следует отличать от выходных параметров схем Y={у1, у2, ..., уп) таких, как полоса пропускания, потребляемая мощность и т. д. Возможны и другие разбиения параметров схем и параметров ССП [20].
В структуре интегрированной САПР присутствуют инвариантные подсистемы, которые являются общими для проблемно-ориентированных систем - система управления базой данных (СУБД), подсистемы документирования, интерактивной машинной графики, адаптивного управления диалогом и т.д.
Проектные задачи схемотехнического проектирования выполняются с помощью проектных процедур синтеза (параметрического и структурного), оптимизации (параметрической и структурной) анализа. Параметрический синтез направлен на определение числовых значений параметров схемных компонентов, обеспечивающих правильное функционирование схемы заданной структуры. Цель структурного синтеза — получение структуры схемы, т. е. состава ее компонентов и способа их соединений между собой.
Задачи определения оптимальных (в том или ином смысле) характеристик схемы путем варьирования параметров ее компонентов называют параметрической оптимизацией. Структурная оптимизация — это обеспечение наилучших значений основных характеристик схемы при целенаправленном изменении первоначально заданной структуры схемы. Такое изменение может иметь место за счет подключения к схеме дополнительных компонентов или путем закорачивания или расщепления произвольной совокупности узлов. Анализ схемы — определение совокупности ее качественных показателей.
Задачи расчета схемы являются составными частями задач анализа схемы и представляют собой проектные операции, направленные на определение отдельных качественных показателей схемы при заданных значениях параметров компонентов и заданной структуре схемы.
В работе [49] дано одно из наиболее конструктивных определений САПР как совокупности инструментов проектировщика. «Функционально применение САПР как инструмента для схемотехнического проектирования представляется итерационным процессом, состоящим в выполнении совокупности проектных процедур П = = {П1, П2, ..., Пп} во взаимодействии трех множеств: множества моделей М={М1 М2, ..., Мп}, множества операций над моделями O={01, 02, ..., Оп} и множества критериев, ограничений и условий проектирования К={K1K2,…Kn}».
Проектные решения схемотехнических САПР
Все рассмотренные выше требования необходимо учитывать на всех этапах разработки специализированного АПР, начиная от этапа семантического моделирования предметной области и заканчивая этапом разработки архитектуры и реализации управляющего web-приложения. Для интеграции специализированного АПР в схемотехническую САПР могут быть использованы технологии встраивания интернет-браузера в состав управляющей подсистемы САПР [1] или же подход на основе создания специализированного web 57 приложения, выполняющего функции управляющей подсистемы web-ориентированной САПР и одновременно обеспечивающего доступ к удаленным базам данных и архиву проектных решений [2].
В архитектурных шаблонах, используемых для построения информационных систем, выделяют следующие семантические слои [19,23,24,25,31]: интерфейсно-управляющий слой, обеспечивает диалоговое взаимодействие с пользователем и вызов необходимых рабочих операций; функциональный слой, реализует основные рабочие операции по обработке данных; слой хранения данных, представляет совокупность структур хранения данных, как на основе отдельных файлов, так и с использованием универсальных БД; слой доступа к данным, является промежуточным звеном между слоем хранения данных и функциональным слоем.
В локальных информационных системах используется традиционная архитектура, построеннаяна основе отдельных модулей при этом каждый семантический слой, предназначенный для выполнения отдельной рабочей операции, включает группу взаимосвязанных модулей, образующих подсистему.Последовательность вызова рабочих операций, а значит и определенных модулей, заранее определена и реализуется пользователем в процессе взаимодействия с управляющей подсистемой, соответствующей управляющему семантическому слою.
При переходе к web-ориентированной архитектуре необходимо систематизировать основные рабочие операции и разнести их между клиентской и серверной частями web-приложения. В соответствии с требованиями к функциональным характеристикам АПР, сформулированными в разделе 2.3, выделим следующий перечень проектных операций, приведенный в таблице 2.1. Таблица 2. № п/п Наименование операции Web-сервер Рабочая станция 1 Авторизация пользователей V 2 Загрузка проектных решений V 3 Выгрузка проектных решений V 4 Поиск проектных решений V 5 Визуализация проектных решений V V 6 Регистрация сеансов доступа V 7 Шифрование проектных решений V 8 Выпуск проектной документации V 9 Вызов внешних приложений V Анализ содержимого таблицы 2.1 позволяет разделить проектные операции на две группы: A. Операции, связанные с хранением, поиском и организацией доступа к проектным решениям; B. Операции, ориентированные на визуализацию и редактирование проектных решений. При реализации распределенной архитектуры АПР целесообразно перенести выполнение операций группы А на web-сервер интернет-ресурсов САПР, где непосредственно хранятся файлы проектных решений, а операции группы B, связанные с модификацией проектных решений выполнять на рабочей станции САПР. В соответствием с таким распределением функций архитектура распределенного АПР будет включать две части: серверную и клиентскую. При работе в распределенном АПР необходимо обеспечить дистанционный вызов рабочих операций и пересылку файлов проектных решений между клиентом и сервером. Для реализации данной возможности архитектуру АПР необходимо дополнить интерфейсно-управляющими web-приложениями, которыеуправляют последовательностью вызова проектных операций, как на стороне сервера так и на стороне клиента. В функции управляющих вэб-приложений должна входить также функция передачи проектных данных между рабочей станцией и сервером.
С учетом данных требований разработана web-ориентированная архитектура распределенногоархива проектных решений, которая приведена на рисунках 2.3 и 2.4.
На рабочей станции САПР (клиентская часть) доступны файлы загруженного проектного решения, с которыми можно выполнять операции редактирования и дополнительной обработки. На стороне клиента имеется возможность использовать архивное проектное решение в САПР для проектирования новых узлов и блоков радиоэлектронной аппаратуры. Необходимыми элементами данной архитектуры являются также IIS-сервер и Интернет-браузер, которые обеспечивают функционирование распределенного АПР в сети Интернет.
Проблема интеграции АПР в схемотехническую САПР может быть решена путем встраивания в состав интерфейсно-управляющей подсистемы САПР модулей для вызова web-приложений АПР. Для реализации хранилища файлов проектных решений целесообразно использовать универсальную клиент-серверную СУБД.
Построение АПР на основе систем электронного документооборота
Модель "сущность—связь" и реляционная модель — это только часть множества современных инструментов представления данных. Один из подходов к обеспечению совместимости систем баз данных с парадигмой объектно ориентированного проектирования связан с расширением системы понятий, лежащей в основе объектно-ориентированных языков программирования, таких как С++ или Java, в направлении поддержки средств постоянного хранения данных. В традиционном программировании подразумевается, что после завершения цикла работы программы ее объекты безвозвратно утрачиваются, в то время как принципиальное условие работы любой СУБД состоит в том, что объекты должны храниться неограниченно долгое время, пока не будут изменены или удалены принудительно, как это происходит в файловых системах. Наиболее известна объектно-ориентированная модель представления данных, называемая ODL (ObjectDefinitionLanguage— язык определения объектов), которая в свое время была стандартизована исследовательской группой ObjectDataManagementGroup (ODMG)[50]. Известна так же объектно-реляционная модель (object-relationalmodel)[50]. Эта модель является частью стандарта SQL, называемого SQL-99 (или SQL: 1999, а также SQL3), и представляет собой вариант расширения обычной реляционной модели за счет формализации многих общепринятых концепций объектно-ориентированного проектирования. Указанный стандарт служит основой для построения объектно-реляционных систем баз данных, каковые сегодня выпускаются всеми основными поставщиками коммерческих СУБД. Эти системы, однако, значительно различаются в деталях практической реализации исходных концепций.
В последнее время разработана модель "полуст рукт урированных" данных(s emistructureddata), призванная разрешить большое число актуальных проблем технологий СУБД, включая, например, необходимость объединения традиционных баз данных с другими источниками информации, такими как Web 82 страницы самой разнообразной структуры[50]. В то время как, объектно-ориентированные или объектно-реляционные системы предполагают использование фиксированных схем для каждого класса или отношения, модель полуструктурированных данных отличается намного более высокой гибкостью представления компонентов информации.
Наиболее ярким практическим воплощением модели полуструктурированных данных является XML (extensibleMarkupLanguage — расширяемый язык разметки). XML по своей сути — это спецификация описания "документов", представляющих собой наборы вложенных элементов данных, функции которых определяются соответствующими тэгами.
Рассмотрим основные понятия объектно-ориентированного проектирования как таковые. Объектно-ориентированное проектирование и программирование заслужили широкое признание как инструмент повышения качества программных проектов и увеличения степени надежности их реализации. Парадигма объектно-ориентированного программирования, впервые воплощенная в языке Smalltalk, пережила бурный рост и приобрела всеобщую популярность с появлением языка С++. В последние годы прокатилась новая волна интереса к объектно-ориентированному программированию, и ее причиной послужило распространение языка Java — мощного и удобного инструмента создания программных приложений, ориентированных на использование в среде WorldWideWeb.
В основе объектно-ориентированной модели лежат следующие понятия: . система поддержкитиповtypes); . класс (class) — тип, которому соответствует набор объектов (objects); . идентификационный номер объекта (objectidentity) — значение, однозначно удостоверяющее подлинность объекта и позволяющее различить его среди других объектов того же класса и всех других классов независимо от содержимого объекта; . наследование{inheritance) — способ иерархической организации классов, при которой каждый "дочерний" класс наследует свойства "родительского" класса. Объектно-ориентированный язык программирования предлагает пользователю обширный набортипов (types), который включает в том числе и атомарные типы (atomictypes), представляющие целые и вещественные числа, булевы значения и строки символов. Допустимы нестандартные типы, основанные на специальных конструкциях языка.
Учитывая использование для разработки приложения web-ориентированного АПР объектно-ориентированного языка программирования С#, для перехода от семантической модели данных к даталогической в диссертации предлагается использовать объектно-реляционную модель данных, которая подробно рассмотрена в четвертой главе диссертации.
Создание Web-приложения АПР ArchiveDBв среде ASP.NETMVC
EntityFramework представляет специальную объектно-ориентированную технологию на базе фреймворка .NET для работы с данными. Если традиционные средства ADO.NET позволяют создавать подключения, команды и прочие объекты для взаимодействия с базами данных, то EntityFramework представляет собой более высокий уровень абстракции, который позволяет абстрагироваться от самой базы данных и работать с данными независимо от типа хранилища. Если на физическом уровне мы оперируем таблицами, индексами, первичными и внешними ключами, но на концептуальном уровне, который нам предлагает EntityFramework, мы уже работает с объектамих[55].
Первая версия EntityFramework - 1.0 вышла еще в 2008 году и представляла очень ограниченную функциональность, базовую поддержку ORM (object-relationalmapping - отображения данных на реальные объекты) и один единственный подход к взаимодействию с БД - DatabaseFirst. С выходом версии 4.0 в 2010 году многое изменилось - с этого времени EntityFramework стал рекомендуемой технологией для доступа к данным, а в сам фреймворк были введены новые возможности взаимодействия с бд - подходы ModelFirst и CodeFirst.
Дополнительные улучшения функционала последовали с выходом версии 5.0 в 2012 году. И наконец, в 2013 году был выпущен EntityFramework 6.0, обладающий возможностью асинхронного доступа к данным.
Центральной концепцией EntityFramework является понятие сущности или entity. Сущность представляет набор данных, ассоциированных с определенным объектом. Поэтому данная технология предполагает работу не с таблицами, а с объектами и их наборами.
Любая сущность, как и любой объект из реального мира, обладает рядом свойств. Например, если сущность описывает человека, то мы можем выделить такие свойства, как имя, фамилия, рост, возраст, вес. Свойства необязательно представляют простые данные типа int, но и могут представлять более комплексные структуры данных. И у каждой сущности может быть одно или несколько свойств, которые будут отличать эту сущность от других и будут уникально определять эту сущность. Подобные свойства называют ключами[55].
При этом сущности могут быть связаны ассоциативной связью один-ко-многим, один-ко-одному и многие-ко-многим, подобно тому, как в реальной базе данных происходит связь через внешние ключи.
Отличительной чертой EntityFramework является использование запросов LINQ для выборки данных из БД. С помощью LINQ мы можем не только извлекать определенные строки, хранящие объекты, из БД, но и получать объекты, связанные различными ассоциативными связями[55].
Другим ключевым понятием является EntityDataModel. Эта модель сопоставляет классы сущностей с реальными таблицами в БД.EntityDataModel состоит из трех уровней: концептуального, уровень хранилища и уровень сопоставления (маппинга). На концептуальном уровне происходит определение классов сущностей, используемых в приложении. Уровень хранилища определяет таблицы, столбцы, отношения между таблицами и типы данных, с которыми сопоставляется используемая база данных.
Уровень сопоставления (маппинга) служит посредником между предыдущими двумя, определяя сопоставление между свойствами класса сущности и столбцами таблиц.
Таким образом, мы можем через классы, определенные в приложении, взаимодействовать с таблицами из базы данных.
Способы взаимодействия с БД: EntityFramework предполагает три возможных способа взаимодействия с базой данных [55]: Databasefirst: EntityFramework создает набор классов, которые отражают модель конкретной базы данных. Modelfirst: сначала разработчик создает модель базы данных, по которой затем EntityFramework создает реальную базу данных на сервере. Codefirst: разработчик создает класс модели данных, которые будут храниться в бд, а затем EntityFramework по этой модели генерирует базу данных и ее таблицы.
При создании приложения был выбран третий подход CodeFirst, которыйподдерживает как генерацию сущностных классов из существующей базы данных, так и создание базы данных из созданной вручную модели объектов С#. Классы моделей приложения включают следующие сущности: Users (пользователи) - предназначен для хранения информации о зарегистрированных пользователях, имеющих право на вход в систему. publicclassUser { publicint Id { get; set; } publicstringUserName { get; set; } publicstring Password { get; set; } publicstring Email { get; set; } publicDateTimeCreatedDate { get; set; } publicstringFirstName { get; set; } publicstringLastName { get; set; } publicstringMiddleName { get; set; } publicstringCompanyName { get; set; } publicstring Department { get; set; } publicstringWorkNumber { get; set; } publicstringMobileNumber { get; set; } publicstring Country { get; set; } publicstring City { get; set; } }