Оптимизация взаимодействия между уровнем бизнес-логики COM+ и уровнем презентации
Как правило, задержка между уровнями распределенного приложения значительно отличается. Вызовы между уровнем презентации и уровнем бизнес-логики часто являются порядком медленнее, чем вызовы между бизнес-уровнем и уровнем данных. В результате состояние удерживаемого состояния становится более дорогостоящим при вызове уровня бизнес-логики.
В следующих разделах рассматриваются способы передачи данных между уровнями презентации и бизнес-логики:
- Передача параметров
- Параметры передачи данных
- Использование шаблона фабрики для передачи данных
- Связанные статьи
Передача параметров
Для прохождения определенного набора данных между уровнем презентации и уровнем бизнес-логики может быть одна строка, несколько строк или сочетание одной строки (например, заголовка) и нескольких строк данных. Наиболее эффективным способом передачи этих сведений между уровнями является один вызов метода. Этот один вызов будет управлять всем набором данных, передаваемым. Это необходимо, если вы не решили контролировать транзакцию с уровня презентации (и сделать все обработка транзакций на уровне презентации идентичным в функции). Корпорация Майкрософт не рекомендует проводить транзакции с уровня презентации, так как вызовы между этим уровнем и уровнем бизнес-логики обычно являются самыми медленными из всех вызовов в многоуровневом приложении.
Одним из способов создания такого метода является передача отдельных строк информации в качестве параметров и передача нескольких строк в виде наборов записей ADO. Наборы записей являются основой методологии доступа к данным Microsoft ADO, и использование наборов записей ADO позволяет передавать все сведения, связанные с одной транзакцией на одном шаге.
Параметры передачи данных
При передаче данных можно учитывать другие варианты. К ним относятся использование списка параметров и наборов записей ADO (как описано выше), просто наборы записей ADO, строки в кодировке XML или массивы структур. В этом разделе рассматриваются все эти параметры.
В следующей таблице показаны области, в которых необходимо обеспечить дополнительную помощь при использовании любого из четырех различных возможностей передачи аргументов. "X" представляет области, в которых необходимо понимать и взвешивать компромиссы в соответствии с потребностями каждого проекта. Старайтесь не принимать решения о передаче аргументов на основе каждого компонента. Преимущества согласованной модели программирования на протяжении всего проекта значительно перевешивают все преимущества оптимизации на основе каждого метода или каждого компонента во всех, но самых экстремальных обстоятельствах. Столбцы описаны в списке, который следует таблице.
| Параллелизм | Глобальная сеть | Развертывание | Сложность | |
|---|---|---|---|---|
| Формат ввода | Значение | |||
| Наборов записей |
X |
X |
X |
|
| XML |
X |
X |
X |
|
| Массивы |
X |
X |
X |
Четыре столбца определяют области, которые следует отслеживать при использовании этого параметра для передачи параметров.
- Столбец параллелизма представляет необходимость в коде или предоставляет механизм, который управляет условиями блокировки при операциях обновления. Так как методы, выполняющие сохранение, могут представлять обновления, могут возникнуть проблемы параллелизма. Два типа блокировки распространены оптимистично и пессимистично. Pessimistic locks запрещает пользователю получать данные для обновления, а другой пользователь может выполнить обновление. Оптимистическая блокировка поддерживает большое количество пользователей, торгуя по вероятности того, что все два пользователя будут обновлять один и тот же документ одновременно. Оптимистическая блокировка вызывает проверка, чтобы увидеть, что данные, хранящиеся в соответствие с данными, на момент получения доступа к копии данных для изменения. Наборы записей ADO обеспечивают автоматическую поддержку оптимистической блокировки. Сценарии обновления, включающие списки параметров одной строки, не обеспечивают достаточную поддержку параллелизма проверка. XML страдает от этой же проблемы, в том случае, что в XML-данных отсутствует блокировка.
- Столбец глобальной сети представляет условия, в которых может возникнуть конфликт передачи в широкой сети (глобальной сети). Если глобальная сеть не имеет достаточной емкости для управления всеми перемещаемых данными в любое время, пользователи приложений испытывают задержки времени отклика. Для поддержки оптимистического параллелизма отключенные наборы записей ADO передают две копии данных с сервера клиенту. Вторая копия используется клиентом для определения наименьшего набора строк обновления для передачи обратно при фиксации изменения. Хотя это сокращает трафик от уровня презентации к данным, дополнительная нагрузка второй копии может быть значительной. Использование наборов записей в качестве единственного средства передачи всех данных, поэтому в два раза больше данных передается между уровнями, за исключением случаев, когда набор строк обновления передается обратно на уровень данных из уровня презентации.
- Столбец развертывания представляет проблемы, связанные с передачей данных, когда требуется специальная технология как на стороне вызывающего, так и компонента сети. Например, при использовании наборов записей ADO необходимо, чтобы компоненты ADO присутствовали как на клиенте, так и на сервере. Средства синтаксического анализа XML также должны присутствовать на обеих сторонах, чтобы избежать необходимости выполнять синтаксический анализ кода в приложениях.
- Столбец "Сложность" указан для всех четырех вариантов выбора и является вопросом предпочтения или предыдущего опыта программирования, который может быть уже установлен в вашей организации разработки. Некоторые люди находят передачу параметров, чтобы быть громоздким и чувствовать, что она добавляет слишком много сложности в проблему программирования. Отслеживание того, какой параметр обрабатывается, и получение их всех видимых в одном окне редактирования может создать логистическую сложность, которую некоторые разработчики находят неуправляемыми.
Метод передачи параметров также может иметь компромиссы, например следующие:
- Параметры могут включать управление несколькими аргументами и типами аргументов, а также решение о том, когда необходимо сделать набор записей параметром.
- Наборы записей ADO могут сократить иерархические связи в параметрах метода до одного или двух аргументов. Это значительно упрощает модель программирования и поддерживает добавление столбцов позже, но также скрывает информационную иерархию. Вставка сведений в набор записей ADO и последующее извлечение его включает в себя знание имен каждого столбца или знание порядка столбцов. Эта ситуация может добавить сложность для других разработчиков компонентов или приложений в проекте.
- XML - это другой спин на скрытой иерархии осложнений, упоминание выше. Программист должен понять использование средства синтаксического анализа XML для получения доступа к информации и часто должны знать имена каждого элемента в наборе данных, прежде чем найти набор данных.
- Массивы структур представляют необходимость общего понимания информации, передаваемой как вызывающей стороной, так и компонентом. Эта необходимость в сопоставлении между двумя системными элементами может привести к трудностям при работе с различными версиями компонентов. Хотя сигнатура метода может не измениться, изменения ожидаемой информации могут отображать несовместимые вызывающие программы.
Так как проблемы сложности, связанные со всеми четырьмя методами передачи параметров, настолько похожи, это является спорным, что существует важная возможность упрощения, связанная с любым выбором.
Использование шаблона фабрики для передачи данных
Одной из важных точек проектирования является простота использования. Когда вы решили использовать наборы записей ADO для передачи структурированного набора сведений обратно на уровень презентации, возникла проблема сложности. Программисты уровня презентации должны понимать структуру этих наборов записей. Более сложная проблема может возникнуть, если требуется несколько сведений для набора данных, передаваемых в наборе записей. Чтобы упростить вопросы, следует рассмотреть возможность создания метода фабрики наборов записей всякий раз, когда вы планируете передавать данные в структурированных наборах записей ADO.
Фабрика наборов записей должна возвращать пустой, но доступный для записи набор записей вызывающей объекту. Этот набор записей должен иметь соответствующие поля (имена и типы данных), чтобы вызывающий клиент не должен знать, как производить набор записей. Этот подход часто называется шаблоном фабрики и является общим шаблоном решения, который решает необходимость создания объекта определенной сложности, не имея необходимости знать нюансы его создания.
Простые варианты проектирования, такие как выбор одного и того же имени параметра для одного и того же фрагмента данных в каждом методе, в котором передается эта информация, позволяет легко изучить метод и узнать, что ожидается. Убедитесь, что порядок, в котором передаются такие аргументы, согласуется во всем семействе методов, обеспечивает точку комфорта, которая применяет конзис режим палатки l.