• Открывайте и закрывайте соединения быстро. Открывайте соединение с базой данных при каждом вызове метода и закрывайте перед его завершением. Соединения никогда не должны удерживаться открытыми между клиентскими запросами, и клиент не должен управлять получением и освобождением соединений. Если клиенту предоставить такую возможность, то возникнет вероятность того, что соединение может не быть закрыто максимально быстро, или может оставаться неадекватно открытым, что наносит ущерб масштабируемости.
• Реализуйте обработку ошибок. Используйте обработку ошибок, чтобы гарантировать закрытие соединения, даже если команда SQL сгенерирует исключение. Помните, что соединения — ограниченный ресурс, и использование их всего на несколько секунд дольше необходимого может пагубно отразиться на общей производительности.
• Следуйте практике дизайна без состояний. Передавайте всю необходимую методу информацию в его параметрах, и возвращайте все извлекаемые им данные через возвращаемое значение. Если вы создадите класс, который поддерживает состояние, его трудно будет реализовать в виде Web-службы или использовать в сценарии балансировки нагрузки. К тому же если компонент базы данных будет размещен вне процесса, то каждый вызов метода потребует заметных накладных расходов, а применение множественных вызовов для установки свойств займет гораздо больше времени, чем единственный вызов метода с передачей всей информации в параметрах.
• Не позволяйте клиенту указывать информацию строки соединения. Это представляет собой риск нарушения безопасности, вероятность сбоя устаревших клиентов и ослабляет эффективность пулов соединений, которые требуют точного совпадения строк соединений.
• Не подключайтесь под клиентским идентификатором пользователя. Как упоминалось в предыдущей главе, возможность вариаций параметров в строке соединения мешает работе пула соединений. Вместо этого полагайтесь на безопасность на основе ролей или на систему на базе билетов (ticket-based system), посредством которой выполняется аутентификация пользователей для выполнения ограниченных операций. Эта модель также работает быстрее, чем попытки выполнения запросов от имени некорректной учетной записи с ожиданием ошибки.
• Не позволяйте клиентам использовать широкие открытые запросы. Каждый запрос должен благоразумно выбирать лишь те строки, которые ему действительно нужны. К тому же, где только возможно, ограничивайте результаты с помощью конструкции WHERE. Например, извлекая записи о заказах, вы можете установить минимальный диапазон дат (или применить SQL-конструкцию вроде ТОР 1000). Без таких предосторожностей ваше приложение может работать хорошо в начале, но замедляться по мере роста базы данных и размера клиентских запросов, которые могут нагружать как базу данных, так и сеть.

 

предыдущая    следующая страница   оглавление

338