Поделиться через

Оптимизация взаимодействия между уровнем бизнес-логики COM+ и уровнем презентации

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

В следующих разделах рассматриваются способы передачи данных между уровнями презентации и бизнес-логики:

Передача параметров

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

Одним из способов создания такого метода является передача отдельных строк информации в качестве параметров и передача нескольких строк в виде наборов записей ADO. Наборы записей являются основой методологии доступа к данным Microsoft ADO, и использование наборов записей ADO позволяет передавать все сведения, связанные с одной транзакцией на одном шаге.

Параметры передачи данных

При передаче данных можно учитывать другие варианты. К ним относятся использование списка параметров и наборов записей ADO (как описано выше), просто наборы записей ADO, строки в кодировке XML или массивы структур. В этом разделе рассматриваются все эти параметры.

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

  Конкурентность Глобальная сеть Развёртывание Сложность
Вход Ценность
Наборы записей
 X
 X
 X
XML
 X
 X
 X
Массивы
 X
 X
 X

Четыре столбца определяют области, которые следует отслеживать при использовании этой опции для передачи параметров.

  • Столбец согласованности обозначает необходимость разработки или предоставления механизма, управляющего блокировкой условий в операциях обновления. Так как методы, выполняющие сохранение, могут представлять обновления, могут возникнуть проблемы параллелизма. Два типа блокировки распространены: оптимистическая и пессимистическая. Пессимистические блокировки запрещают пользователю изменять данные, если у другого пользователя есть возможность выполнить обновление. Оптимистическая блокировка поддерживает большое количество пользователей, торгуя по вероятности того, что все два пользователя будут обновлять один и тот же документ одновременно. Оптимистическая блокировка предполагает проверку того, что хранящиеся данные соответствуют данным в момент, когда копия данных была получена для изменения. Наборы записей ADO обеспечивают автоматическую поддержку оптимистической блокировки. Сценарии обновления, включающие списки параметров одной строки, не обеспечивают достаточную поддержку проверки параллелизма. XML страдает от этой же проблемы, так как в XML-данных отсутствует осведомленность о блокировке.
  • Столбец глобальной сети представляет условия, в которых может возникнуть конфликт передачи в широкой сети (WAN). Если глобальная сеть не имеет достаточной емкости для управления всеми перемещаемых данными в любое время, пользователи приложений испытывают задержки времени отклика. Для поддержки оптимистического параллелизма отключенные наборы записей ADO передают две копии данных с сервера клиенту. Вторая копия используется клиентом для определения наименьшего набора строк обновления для передачи обратно при фиксации изменения. Хотя это сокращает трафик от уровня презентации к данным, дополнительная нагрузка второй копии может быть значительной. Использование наборов записей в качестве единственного средства передачи всех данных в два раза увеличивает объем передаваемых данных между слоями, за исключением случаев, когда набор строк обновления передается обратно на слой данных из слоя презентации.
  • Столбец развертывания представляет собой проблемы, связанные с передачей данных, когда требуется специальная технология как на стороне вызывающего, так и на стороне компонента сети. Например, при использовании наборов записей ADO необходимо, чтобы компоненты ADO присутствовали как на клиенте, так и на сервере. Средства синтаксического анализа XML также должны присутствовать на обеих сторонах, чтобы избежать необходимости выполнять синтаксический анализ кода в приложениях.
  • Столбец сложности применим ко всем четырем вариантам выбора и зависит от предпочтений или предыдущего опыта работы с программными моделями, который может быть уже установлен в вашей организации, занимающейся разработкой. Некоторые люди считают передачу параметров утомительной и чувствуют, что она добавляет слишком много сложности в проблему программирования. Отслеживание того, какой параметр обрабатывается, и сделать так, чтобы они все были видны в одном окне редактирования, может создать логистическую проблему, которую некоторые разработчики считают неуправляемой.

Метод передачи параметров также может иметь компромиссы, например следующие:

  • Параметры могут включать управление несколькими аргументами и типами аргументов, а также решение о том, когда необходимо сделать набор записей параметром.
  • Наборы записей ADO могут сократить иерархические связи в параметрах метода до одного или двух аргументов. Это значительно упрощает модель программирования и поддерживает добавление столбцов позже, но также скрывает информационную иерархию. Вставка сведений в набор записей ADO и последующее извлечение его включает в себя знание имен каждого столбца или знание порядка столбцов. Эта ситуация может добавить сложность для других разработчиков компонентов или приложений в проекте.
  • XML — это другой подход к скрытой иерархии, упомянутой выше. Программист должен понять использование средства синтаксического анализа XML для получения доступа к информации и часто должны знать имена каждого элемента в наборе данных, прежде чем найти набор данных.
  • Массивы структур требуют общего понимания информации, передаваемой как вызывающей стороной, так и компонентом. Необходимость в карте, которую используют два системных элемента, может вызвать трудности при работе с различными версиями компонентов. Хотя сигнатура метода может не измениться, изменения ожидаемой информации могут сделать вызывающие программы несовместимыми.

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

Использование шаблона фабрики для передачи данных

Одной из важных точек проектирования является простота использования. Когда вы решили использовать наборы записей ADO для передачи структурированного набора сведений обратно на уровень презентации, возникла проблема сложности. Программисты уровня презентации должны понимать структуру этих наборов записей. Более сложная проблема может возникнуть, если требуется несколько сведений для набора данных, передаваемых в наборе записей. Чтобы упростить вопросы, следует рассмотреть возможность создания метода фабрики наборов записей всякий раз, когда вы планируете передавать данные в структурированных наборах записей ADO.

Фабрика наборов записей должна возвращать пустой, но доступный для записи набор записей вызывающему объекту. Этот набор записей должен иметь соответствующие поля (имена и типы данных) уже настроены, чтобы вызывающему клиенту не требовалось знать, как формировать набор записей. Этот подход часто называется шаблоном фабрики и является общим шаблоном решения, который решает необходимость создания объекта определенной сложности без необходимости знать нюансы его создания.

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

Оптимизация взаимодействия между уровнем бизнес-логики COM+ и уровнем данных

  • Last updated on