Открыть главное меню
Центр поддержки системы бронирования β

Модуль (термин)

Версия от 03:48, 29 марта 2012; Лидия Чаплин (обсуждение | вклад)

Модуль - составная часть системы, функционально завершенная и обладающая независимыми характеристиками, что позволяет делить программу на фрагменты без потери ее целостности.

Система Nemo состоит из модулей, что дает возможность подобрать только тот функционал, который действительно нужен клиенту.

Содержание

Список модулей системы Nemo

  • Ядро системы: служба авторизации и управления пользователями, панель управления.
  • Стандартный интерфейс к поиску и бронированию авиабилетов с использованием технологии GDS Sabre — LowFareSearch (LFS).
  • Модуль поиска авиабилетов с использованием технологии GDS Sabre — BargainFinderMax (BFiM).
  • Модуль автоматической выписки электронного билета BSP (e-Ticketing) в GDS Sabre.
  • Модуль поиска и бронирования авиабилетов в GDS Galileo.
  • Модуль по продаже билетов авиакомпаний-дискаунтеров (LowCost).
  • Модуль выбора места при бронировании (Seat Mapping).
  • Модуль внесения данных карты лояльности постоянного пассажира при бронировании (Loyalty Card).
  • Шлюз к Gulliver's Travel Associates — интерфейс по поиску и бронированию отелей, трансферов и экскурсий из системы GTA.
  • Справочник: «Гео-объекты».
  • Справочник: «Отели».
  • Справочник «Аэропорты».
  • Справочник «Авиакомпании».
  • Справочник «Типы воздушных судов».
  • Модуль «Корзина покупателя».
  • Модуль динамического пакетирования (DynaPack).
  • Шлюз по приему онлайн оплаты к UFS.
  • Шлюз по приему онлайн оплаты к Chronopay.

Основные модули системы в версии Nemo 2.0

  • Core, Main – базовые модули, содержащие самые общие для всех серверов объекты и действия. В них входят работы с формами, подключение к БД, логирование, работа со списками, панель управления и т.д. Core в отличие от Main содержит системный код, вроде подключений к БД. Main – общие для всех серверов элементы бизнес логики, страницы панели управления.
  • Zend – модуль содержит библиотеки Zend Framework. В частности, в проекте используется генерация WSDL на основе механизмов ZendAutoDiscover.
  • Services – базовый модуль для построения сервиса. Именно его функциональность необходимо расширять при создании своего сервиса.
  • Schemas – WSDL модели общие для всех серверов по бронированию услуг. Содержит схемы объектов перелетов, отелей, их бронирований и т.д. Используется в паре с модулем конкретного сервера.
  • Flights – модуль работы с авиа-перелетами. Кроме описание авиа-объектов, содержит логику по основным действиям авиа.
  • Hotels – модуль работы с отелями — отельные объекты и действия над ними.

Модули GDS, WBS – модули добавляют себя в списки поставщиков Flights и Hotels и используются этими модулями для совершения действий.

  • FlightsServices – сервер Авиа.
  • HotelsServices – отельный сервер.
  • PaymentServices – платежный сервер.
  • OrderServices – сервер заказов.

Структура модуля

Модуль состоит из следующих папок и файлов:

  • Event/ – каталог классов с событий и обработчиков;
  • Controller/ – каталог размещения контроллеров панели управления и сервисов;
  • Model/ – бизнес логика приложения и модели предметной области;
  • Source/ – классы уровня доступа к данным;
  • configs/ – файлы конфигурации;

admin/ - каталог конфигурационных фалов форм menu.php – добавление пунктов главного меню

  • lang/ - переводы;
  • migrations/ - дампы миграций БД по данному модулю;
  • temoplates/ - html шаблоны модуля;
  • bootstrap.php – загрузчик модуля;
  • autoloader.php – правила для автозагрузчика. Как правило тут устанавливается что классы из Model не содержат это слово своем названии;
  • routes.php – роуты, адресация страницы панели управления.

Добавление нового модуля

Модули должны иметь ТОЛЬКО одностороннюю зависимость от других модулей - это значит, что модуль B может зависеть от модуля A, но при этом модуль A не должен «знать» о существовании модуля B. Зависимость модулей может выражаться в наследовании классов, расширении модулей списками, привязке к событиям, прямых обращениях к классам других модулей. Расширение модулей списками — парадигма проекта, позволяющая на основании списка в реестре настроек (Core_Registry) реализовывать фабрики, не прописывая жестко в коде перечислений, к примеру, поставщиков и их фабрик.

Условно такие списки хранятся в ветке «module», т.е. Core_Registry::instance('module').

Например, в классе модуля авиа Flights_Module есть список flights.factory, и для удобства определены методы, добавляющие в него фабрики и возвращающие список. При таком подходе в классе модуля произвольной GDS можно обратиться к модулю авиа и ддополнить фабрику этой GDS. Авиа модуль же, когда ему нужно получить нужную фабрику, просто обращается к этому списку и берет ее по имени сервиса. Таким образом, мы получаем дополнительные возможности по исключению взаимозависимостей в модулях.

Схема добавления нового модуля:

1) Создать каталог модуля в папке /modules, к примеру MyMod;
2) Создать необходимые подкаталоги, как минимум Model;
3) В папке Model добавить класс данного модуля — MyMod_Module в котором определим метод load. Этот метод вызывается при загрузке модуля и именно здесь нужно расширять списки других модулей, если требуется.
4) Заполним файлы autoload.php и bootstrap.php. В autoload заносятся дополнительные правила для автозагрузчика. Сделаем так, чтобы папку Model не требовалось писать в имени класса: 

$rules = array(
		'MyMod' => 'MyMod_Model'
	);

А в файл bootstrap пропишем параметры загрузки нашего модуля: его имя, его загрузчик и его зависимости от других модулей (к примеру, Core и Main): 

$module = array(
		'name' => 'MyMod',
		'loader' => 'MyMod_Module',
		'require' => 'Core,Main',
	);

Модуль успешно создан.

Добавление нового модуля сервера

Процесс схож с обычным добавлением модуля. В классе нашего модуля в методе load запишем добавление в список расширения базового модуля сервисов: 

ServerKit::getContext()->getModule('Services')->addService('MyServices');

После этого автозагрузчик и генератор WSDL «увидят» классы и модели нового сервиса. Все веб-сервисные классы должны иметь версию, поэтому и в контроллерах и в моделях необходимо создать папку version/номер_версии/ и далее - нужные файлы. Версия по умолчанию - 1.0. Модели в веб-сервисах — это специальные классы с public полями и комментариями, по которым генерируется WSDL файл.

Полноценные наборы моделей состоят из нескольких элементов:

  • Сервер с доступными методами.
  • Ветка классов запроса.
  • Ветка классов ответа.

Под cервером здесь понимается смысловой набор методов, посвященный одной теме (например, Поиск). Категории содержат группу серверов (к примеру, есть категория Отели, а в ней серверы поиска, дополнительной информации и т.д.).

Правила размещения:

БзкуЮModel/version/<номер версии>/<имя категории>/...

Внутри категории:

  • Request / - ветки запросов
  • Response / - ветки ответов
  • .php классы описания серверов

Детальнее можно посмотреть на имеющихся примерах.

Внутри метода класса сервера обязателен код вида: 

/**
	 *  <Описание>
	 *
	 * @param <Тип оболочки запроса> $RequestBin
	 * @return <Тип оболочки ответа> $responseBin
	 */
	public function <Метод> ($RequestBin)
	{
		return parent::<Метод> ($RequestBin, new <Тип оболочки ответа> ());
	}

Остальная логика ожидается в соответствующем контроллере/экшене.

Вызов этих методов клиентом происходим по имени. Список имен и соответствующих сеhверов/методов задается в файле 

Model/version/<номер версии>/routes.php

Пример серверного модуля - MovieServices - размещен в ветке разработчиков.

См. также

Источник — https://support.nemo.travel/index.php?title=Модуль_(термин)&oldid=1675
'