Проектирование системы. 
Анализ инженерных сетей. 
Поиск оптимального пути

Далее нужно было спроектировать базу данных для системы. Процесс проектирования схемы базы данных был затронут выпускной квалификационной работе. Здесь же вкратце распишем, с помощью какой технологии база данных будет реализована. Для этого будет использоваться версия LocalDB из СУБД SQL Server 2012. Эта версия автоматически устанавливается вместе с VisualStudio 2012, следовательно, не нужно устанавливать дополнительные средства для её разработки. SQL Server Express LocalDB — это упрощенная версия SQL Server, обладающая множеством возможностей по программированию баз данных, аналогичных SQL Server. LocalDB выполняется в пользовательском режиме, и его можно установить быстрее, с меньшим числом требований и без конфигурации[12]. Эта версия как раз специально предназначена для разработчиков приложений[9], поэтому в ней доступны только локальные подключения.

После этого необходимо переходить к проектированию непосредственно веб-приложения. Начинать нужно с проектирования модели как главной части MVC-приложения. Для взаимодействия объектов модели с базой данных будет использоваться шаблон «Репозиторий». Он позволяет абстрагироваться от конкретных подключений к источникам данных и является промежуточным звеном между классами, непосредственно взаимодействующими с данными, и остальной программой[13]. С помощью него можно легко менять подключение к одной базе данных на другое или использовать несколько подключений в процессе работы приложения. Например, если мы имеем подключение к базе данных MS SQL Serverи вдруг захотим сменить его на подключение к базе данных MySQL, то нужно будет изменить всего лишь одну строку кода в приложении.

Для непосредственного доступа к базе данных будет использоваться платформа EntityFramework, которая является ORM-системой для платформы .NET. ORM (Object-relational mapping) — это технология, которая позволяет связать таблицы базы данных с классами ООП, то есть позволяет работать с таблицами, столбцами и строками реляционной базы данных с помощью обычных объектов. Кроме того, EntityFramework позволяет использовать технологию LINQ для работы с объектами модели вместо языка SQL. Также EntityFramework поддерживает возможность reverse engineer code first, при которой по созданной базе данных с помощью этого фреймворка генерируются классы модели, классы, описывающие связи между свойствами классов модели и столбцами базы данных и класс контекста базы данных.

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

В соответствии с шаблоном MVC и задачами, поставленными в данной работе, после проектирования доменной модели необходимо перейти к проектированию контроллера. В нашей работе необходимо создать 2 контроллера: первый будет отвечать за отображение данных модели в различных представлениях, а второй будет управлять авторизацией пользователей. При этом к первому контроллеру должны иметь доступ только авторизованные пользователи.

Теперь, чтобы узнать, какие методы действия нам нужно создать в контроллерах, необходимо продумать представления. Схема нужных представлений и переходов между ними представлена на рисунке 2.2.

Рисунок 2.2 Схема представлений Согласно схеме представлений, необходимо реализовать 8 методов действий для контроллера HomeController, который отвечает за отображение данных модели в представлениях. При этом для одного представления Search1 нужно 2 метода действия с одинаковым именем Search1: первый метод с атрибутом HttpGet обрабатывает http-запрос Get по адресу http://localhost:9598/Home/Search1,а второй метод с атрибутом HttpPost обрабатывает http-запрос Post по этому же адресу. Этот метод применяется, когда пользователь вводит данные о начальной и конечной точке маршрута и отправляет её на сервер. Get-запрос является тем, что браузер генерирует после клика по гиперссылке. Этот вариант действий будет отвечать за отображение начальной пустой формы. Метод действия с атрибутом HttpPost будет отвечать за получение отправленных данных и решать, что с ними делать. Аналогичная ситуация и с представлением Search2.

Вроде бы этот вариант хорош и должен работать. Но всё дело в том, что визуализация помещения и оптимального пути на стороне клиента идёт с помощью функций библиотеки WebGL для языка JavaScript, позволяющей создавать на нём интерактивную 3D-графику. А с помощью средств этого языка нельзя обрабатывать объекты С#, передаваемые в представление с помощью метода View (объект_С#). Решить проблему можно с помощью формата JSON (JavaScriptObjectNotation), который является независимым от языка способом выражения данных[9]. Для этого применим методы действия, которые возвращают не представление ViewResult, а данные JsonResult. Эти методы будут вызываться из представления по виртуальному клику по Ajax-ссылке. Для обработки полученных данных в представлении должна быть создана специальная функция на языке JavaScript. В результате получается, что вместо методов действия ViewResult [HttpPost]Search1 и ViewResult [HttpPost]Search2 нужно создать, соответственно, методы JsonResultGetRoute (int start, int finish) и JsonResult Search2Json (int finish, int port).При этом все данные будут визуализироваться в одном представлении Search1, поэтому представление Search2 и, следовательно, метод ViewResult [HttpGet]Search2 будут не нужны.

Контроллер авторизации AccountController будет создан автоматически при создании проекта по шаблону. После создания он будет нуждаться лишь в незначительных доработках, связанных с защитой нужных контроллеров от неавторизованного доступа. Теперь хранилище, модель и контроллеры веб-приложения спроектированы. Представления будут проектироваться другим разработчиком, который создаёт пользовательский интерфейс приложения. Следующим этапом данной работы будет являться реализация спроектированных компонентов.