ПОСТРОЕНИЕ АРХИТЕКТУРЫ ПРИЛОЖЕНИЯ
Любое классическое приложение, ориентированное на использование в среде Интернет, имеет несколько уровней обработки и представления данных, среди которых можно выделить:
- уровень хранения данных или просто хранилище данных, где на данные накладываются ограничения связанные с особенностями хранения данных в выбранной СУБД
- уровень бизнес логики, где применяются, так называемые внешние логические ограничения, накладываемые особенностями предметной области
- уровень пользовательского представления данных, где информация обрабатывается непосредственно перед выводом пользователю и оформляется в зависимости от его требований и предпочтений
Проектирование системы требует обязательного рассмотрения вопросов обработки и представления данных на всех уровнях. Последовательность действий при этом обычно следующая: изучение предметной области, разработка инфологической модели представления данных, разработка датологической модели представления данных с учётом выбранной СУБД, внешняя (имеется ввиду в коде программы) реализация правил вносимых особенностями предметной области, разработка интерфейса пользователя и системы управления отображаемыми данными.
При применении CS проектирование системы значительно упрощается. Разработка любого проекта начинается с развёртывания прототипа сайта с необходимыми ресурсами и приложениями. Прототип содержит все возможные готовые подсистемы и шаблоны некоторых ASP страниц.
Любая готовая подсистема, входящая в состав Commerce Server, имеет свою спроектированную подсхему данных, состоящую из нескольких заранее связных между собой таблиц. Работа с каждой подсхемой данных осуществляется с использованием хранимых процедур и триггеров. В таких заранее спланированных схемах, данные обычно хранятся во второй нормальной форме или вообще не нормализованными, что однако позволяет добиваться максимального быстродействия при решении стандартных задач.
Заранее спроектированные схемы данных каждой из подсистем позволяют учитывать также часть основных правил бизнес логики, обычно действующих при реализации этих подсистем.
Так, например, в продуктовом каталоге обязательным атрибутом продукта является цена, которая не может быть отрицательным значением. Разработчик может создавать новые операции преобразования данных и определять последовательность их выполнения с помощью, так называемых, Pipeline. Commerce Server содержит также богатый набор средств для построения уровня пользовательского представления данных, для которого используются Active Server Pages. Все страницы сайта обычно выполняются с использованием нескольких шаблонов, поставляемых в комплекте с Commerce Server, однако разработчик Web-приложения может легко сам разработать собственный шаблон и сами страницы, ограничиваясь только своей фантазией. В каждую страницу сайта встраиваются готовые объекты, от конфигурации которых зависит функциональность конечного решения. Объекты выполнены в соответствии с Component Object Model (COM). COM-объекты имеют собственные интерфейсы прикладного программирования (API) для языков Visual Basic Script Edition и Visual C++. Использование Commerce Server в создании систем электронной коммерции позволяет значительно упростить этапы разработки, поскольку разработчику остаётся только настроить уже существующую модель. Это становиться возможным также за счёт некоторого однообразия задач, для решения которых применяется Commerce Server, и благодаря тесной интеграции с Microsoft SQL Server и MS IIS. Как результат - существенная экономия ресурсов и сокращение сроков реализации и внедрения проекта за счёт использования готовой инфраструктуры при построении своей системы электронной коммерции.
