Book.od.ua Книги для вашего бизнеса



Одесская библиотека бизнес литературы
полезные книги для бизнеса

1.16. Изменение адреса клиента. Продолжение.

Как отмечалось выше, для преобразования канонического формата сообщений в формат, используемый приложениями, применяются трансляторы сообщений. Отсутствие транслятора сообщений Web-интерфейса объясняется тем, что формат последнего был взят за основу канонической модели данных (Canonical Data Model, с. 367). Это может ограничить гибкость решения, если мы захотим предоставить клиентам другой способ изменения своих личных данных, однако на данный момент такой подход выглядит вполне оправданным.
Изменение адреса клиента
Поскольку обе системы хранят адреса клиентов в реляционных базах данных, обновление последних осуществляется с помощью адаптеров канала.
Так какой же из двух подходов к обновлению данных об адресах клиентов является более предпочтительным? В рассматриваемой ситуации объем трафика сообщений не превышает сотни заказов в день, поэтому оба способа вполне эффективны. Основным фактором, который может повлиять на выбор того или иного решения, является внутренняя структура используемых приложений. Некоторые приложения позволяют внести обновленные сведения в базу данных только через свой уровень бизнес-логики. К примеру, приложение может провести дополнительную проверку адреса, создать запись в журнале событий и даже отправить клиенту электронное письмо с уведомлением о смене адреса. Выполнять все эти действия при обработке каждого заказа, конечно же, излишне. В данном случае имеет смысл прибегнуть ко второму подходу, т.е. проводить обновление личных данных клиента только при их фактическом изменении.
В целом же мы отдаем предпочтение таким строго определенным, самодостаточным операциям, как ''Изменить адрес'' и ''Разместить заказ'', потому что они допускают более гибкое управление бизнес-процессами. В конечном итоге все сводится к вопросу детализации интерфейса и связанным с ней преимуществам и недостаткам. Интерфейсы с высокой степенью детализации могут замедлить работу системы по причине большого числа вызовов удаленных процедур или пересылаемых сообщений. К примеру, рассмотрим интерфейс, предоставляющий отдельные методы для изменения полей в адресе клиента. Этот подход мог бы стать эффективным при условии, что взаимодействие происходит в пределах одного приложения. Если же речь идет об интеграционном решении, отправка шести или семи сообщений для обновления адреса клиента является непозволительной роскошью. Кроме того, интерфейсы с высокой степенью детализации предполагают сильное связывание компонентов. Если к адресу клиента будет добавлено дополнительное поле, нам пона­добится внести изменения во все приложения, которые могут обновить адрес.
Интерфейсы с низкой степенью детализации лишены описанных выше недостатков, однако слишком низкая степень детализации может существенно ограничить гибкость решения. Если операции ''Отправить счет'' и ''Изменить адрес'' будут объединены в одну внешнюю функцию, мы не сможем изменить адрес без отправки счета. Таким образом, нужно искать ''золотую середину'', определяя степень детализации интерфейса, исходя из особенностей каждого конкретного сценария.


Понравился материал? Поделитесь с друзьями!

<< Предыдущая статьяСледующая статья >>
1.15. Изменение адреса клиента 1.17. Обновление каталога товаров





Убедительная просьба при использовании любых материалов Одесской электронной бизнес-библиотеки ставить активную ссылку на наш сайт. По всем вопросам касательно сайта пожалуйста пишите на почту
      Карта сайта