ПОСТРОЕНИЕ МАШТАБИРУЕМОГО ПРИЛОЖЕНИЯ

Объекты данных

Служебные объекты

Инфраструктурные объекты

Полная объектная модель

В результате полная объектная модель, включая служебные объекты Search, FireAndForget (пожар и забыть) и XML, приобретает вид:

 

Database. Введение инфраструктурного объекта Database преследует цели: упрощение взаимодействия с БД (объект ADO Connection)Б добавление нескольких функций обработки заказа и обеспечение прямого доступа к объекту ADO Connection. Объект Database недоступен из кода ASP.

 

Catalog. Доступ к каталогу товаров. Этот объект позволяет формировать отделы магазина и соответствующие товары, а также поддерживает запросы по названию компании-производителя, поставщику, отделу и категории товара. Объект создает экземпляры объекта данных Product.

Customers. Управление покупателями (клиентами). Объект регистрирует покупателя в специальной области сайта и может формировать новых покупателей в БД с занесением сведений об их адресах и кредитных карточках.

Orders. Управление заказами. Преобразует текущее содержание корзины в заказ и пересылает заказ по конвейеру обработки. Возвращает сведения об аудите.

Search. Поиск товаров в каталоге.

FireAndForget. Отправка сообщений электронной почты покупателям и посетителям в заданный день и заданное время. Поддерживает определенную часть стратегии работы с покупателями.

XML. Публикация информации из БД в виде XML, а также импорт данных XML в нашу торговую систему.

 

Product. Представляет один из товаров, хранящихся в БД. Возвращает информацию о себе. Обеспечивает динамическое получение и установку атрибутов данных, а также добавление/получение данных об адресе, кредитной карточке и предыдущих заказах клиента.

Customer. Представляет хранящиеся в БД сведения об одном из покупателей, возвращает информацию о себе, включая данные об адресе, кредитной карточке и предыдущих заказах клиента.

Order. Представляет хранящиеся в базе данных сведения об одном из заказов. Возвращает информацию о себе, в т. числе, данные об адресе и кредитной карточке клиента и о содержимом заказа.

Basket. Представляет одну карту (корзину), хранящуюся в БД. Чаще всего этот объект содержит корзину текущего покупателя. Возвращает содержимое корзины и итоговые сведения: общую стоимость и количество наименований товаров.

Говоря о создании объектной модели, нельзя обойти вниманием вопросы построения масштабируемого приложения. Основу масштабируемого приложения составляют две концепции (любой объект занимает память, поэтому масштабируемость достигается снижением требований к памяти приложения):

  1. Создавать объекты только при необходимости. (Принцип Jast-in-Time Activation – активация по мере необходимости)
  2. Создавать как можно меньше экземпляров.

Экземпляр Visit требуется для каждого запроса страницы с сервера. Мы будем создавать один объект для страницы. Поэтому не нужно реализовывать множественный доступ к этому объекту. На основе Visit будут формироваться другие служебные объекты, открывающие доступ к бизнес-правилам, которые обеспечат обращение к экземплярам объектов данных.

В ряде случаев для одной страницы может потребоваться несколько объектов одного типа (например, для сравнения сведений о двух покупателях), но мы не станем пользоваться более чем одним экземпляром служебного объекта одного и того же вида. Если потребуется дополнительный объект Customers, то все необходимые действия (до конца работы со страницей) будут обеспечиваться этим же самым объектом Customers.

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

Это делается по двум причинам:

  1. Для каждого экземпляра объекта Visit будет присутствовать только один экземпляр объекта Catalog. Поскольку допустимо наличие лишь одного экземпляра Visit на страницу, мы будем иметь для этой страницы не более одного объекта Catalog.
  2. Объект Catalog создается только при необходимости/

Посмотрим, как это отразится на работе приложения. Если при инициализации объект Visit создает экземпляры всех 6 объектов, то для одного сеанса потребуется 7 объектов (6 + Visit), а для 1000 сеансов – 7000 объектов. Однако при формировании объектов только по требованию количество объектов снизится и будет в диапазоне от 1000 до 7000 в зависимости от использования страницы. Реальная оценка приводит к применению 2-3 служебных объектов для одной страницы (1000-3000). Создание объектов по требованию позволит снизить влияние ресурсов на работу приложения, поскольку сокращаются требования к ресурсам, и улучшается масштабируемость приложения.

 

Лекция 3.

Некоторые комментарии о необходимой базе для организации е-коммерции (электронного магазина)

Оборудование, необходимое для работы с Интернет.

  1. ПК Pentium III, IV.
  2. 128-256 Mб ОП
  3. Жесткий диск максимального объема
  4. 17 дюймовый монитор и видеоадаптер с 2 Мб памяти
  5. Модем с достаточной скоростью передачи.
  6. Броузер
  7. Доступ к Интернет.
  8. Редактор HTML

Электронный магазин – это прикладная система, построенная с использованием технологии системы электронной коммерции.

Провайдер электронной коммерции – это организация, предоставляющая услуги по осуществлению платежей в Интернете, а также и другие услуги для организации ЭК. Основные средства платежа – электронные карты и электронные наличные. В роли провайдеров ЭК выступают фирмы, тесно связанные с банковскими структурами и с Интернет-провайдерами.

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

Структура затрат на создание электронного магазина включает следующие составляющие: аппаратное обеспечение, программное обеспечение, маркетинговые расходы, расходы на сопровождение системы (содержание дополнительного персонала, обучение, поддержание работоспособности сервера).