Somasegar S., Guthrie Scott. Руководство Microsoft по проектированию архитектуры приложений
Подождите немного. Документ загружается.
Если для сохранения или совместного использования данные состояния должны
передаваться через границы процессов и сетей, обеспечьте их сериализуемость.
Правильно выбирайте хранилище состояния. Хранение состояния в процессе или в
памяти обеспечит наилучшую производительность, но эта техника может
использоваться, только если состояние не должно сохраняться между повторными
запусками процесса или системы. Если хотите, чтобы данные состояния были
доступны после перезапуска процесса или системы, сохраняйте их на локальном
диске или локальном SQL Server. Если состояние является критически важным
аспектом приложения, или если данные состояния должны использоваться
совместно несколькими компьютерами, храните состояние централизованно,
например, на выделенном SQL Server.
Валидация
Проектирование эффективного механизма валидации имеет большое значение с точки зрения
обеспечения удобства и простоты использования и надежности приложения, в противном
случае, оно может остаться открытым для несогласованности данных и нарушений бизнес-
правил, а также обеспечивать неудовлетворительный уровень взаимодействия с
пользователем. Кроме того, приложение может оказаться уязвимым к таким угрозам
безопасности, как межсайтовые атаки внедрением сценариев, атаки типа внедрение SQL-кода,
переполнение буфера и другие атаки посредством входных данных. Четкого и
исчерпывающего определения действительного или злонамеренного ввода нет. Возможные
риски, обуславливаемые злонамеренным вводом, зависят также от того, как приложение
использует ввод. При проектировании стратегии валидации руководствуйтесь следующими
рекомендациями:
По возможности реализуйте позитивную валидацию с использованием списков
разрешенного ввода. Намного проще расширить список разрешенного ввода, чем
пытаться определить все варианты некорректного ввода.
Для проверки безопасности не полагайтесь только на проверку на стороне клиента.
Используйте проверку на стороне клиента для обеспечения обратной связи
пользователю и улучшения взаимодействия с пользователем. Всегда проверяйте
ввод на наличие неверных или злонамеренных данных на стороне сервера,
поскольку проверка на стороне клиента может быть без труда подделана.
Если необходимо обеспечить повторное использование подхода к валидации,
реализуйте его централизованно, вынося функциональность валидации в
отдельные компоненты, или обратитесь к библиотекам сторонних производителей,
таким как Enterprise Library Validation Block (Блок валидации Enterprise Library)
группы patterns & practices. Это позволит создать единый механизм валидации для
всех слоев и уровней приложения.
Ограничивайте, отклоняйте и очищайте пользовательский ввод. Иначе говоря,
исходите из предположения о том, что весь пользовательский ввод является
злонамеренным. Определите границы доверия и проверяйте длину, формат, тип и
диапазон всех вводимых данных, пересекающих границы доверия.
Более подробно проектирование стратегии валидации рассматривается в разделе «Этапы
проектирования стратегии валидации ввода и данных» далее в данной главе.
Этапы проектирования стратегии кэширования
Кэширование может играть решающую роль в повышении производительности.
Исключительно важно спроектировать соответствующую стратегию кэширования, потому что
неправильный выбор методик может негативно сказаться на производительности.
Рассматриваемые далее этапы проектирования помогут выработать правильную стратегию
кэширования для приложения.
Шаг 1 – Выбор данных, подлежащих кэшированию
В ходе проектирования приложения важно определиться с тем, какие данные годятся для
кэширования. Для каждого слоя приложения создайте список данных, которые могут быть
кэшированы. Рассмотрите возможность кэширования следующих типов данных:
Общие данные приложения. Рассмотрите возможность кэширования статических
данных, которые используются всеми пользователям приложения. Примерами
таких данных являются списки продуктов и сведения о продуктах.
Относительно статические данные. Рассмотрите возможность кэширования
полностью статических данных или данных, которые меняются нечасто, например,
константы или фиксированные значения, считываемые из конфигурационного
файла или базы данных.
Относительно статические Веб-страницы. Рассмотрите возможность кэширования
вывода Веб-страниц или частей Веб-страниц, которые меняются нечасто.
Параметры хранимых процедур и результаты запросов. Рассмотрите возможность
кэширования часто используемых параметров и результатов запросов.
Шаг 2 – Выбор места кэширования данных
При принятии решения о месте кэширования данных обычно необходимо рассмотреть два
вопроса: физическое размещение кэша и его логическое размещение.
Физически кэш размещается либо в памяти, либо на диске в файлах или базе данных.
Кэширование в памяти может осуществляться с помощью механизма кэширования ASP.NET,
Enterprise Library Caching Application Block или механизма распределенного кэширования в
памяти, такого как проект Microsoft под кодовым названием Velocity или технология
Memcached от компании Danga Interactive. Размещайте кэш в памяти, если приложение часто
использует данные; если кэшированные данные относительно часто меняются, и их
приходится довольно часто запрашивать повторно; и если объем кэшированных данных
относительно мал. Размещайте кэш в системе или базе данных, если использовать данные из
хранилища кэша более эффективно по сравнению с их запросом из исходного хранилища; если
кэшированные данные относительно редко меняются; и если сервисы для повторного запроса
данных не всегда доступны. Подход с хранением кэша на диске также идеален при большом
объеме кэшированных данных, или если кэшированные данные должны сохраняться при
перезапусках процесса или компьютера.
Логическое размещение кэша – это его место в логике приложения. Важно кэшировать
данные в максимальной близости к месту их использования. Это обеспечит снижение объема
необходимой обработки, сокращение количества обращений к сети и времени отклика
приложения и повышение производительности. Принимая решение о логическом
размещении кэша данных, руководствуйтесь следующими рекомендациями:
Кэшируйте на клиенте данные, характерные для страницы или пользователя;
данные, не содержащие конфиденциальных сведений; и данные небольшого
объема.
Кэшируйте на прокси-сервере или Веб-сервере (для Веб-приложений)
относительно статические страницы, часто запрашиваемые клиентами; страницы,
обновляемые с известной периодичностью; или результаты, возвращаемые Веб-
сервисами. Также используйте этот подход для страниц, которые могут
формировать разный вывод в зависимости от параметров HTTP, и эти параметры
меняются нечасто. Это особенно полезно при небольшом диапазоне выходных
данных.
Кэшируйте в слое представления относительно статический вывод страниц;
небольшие объемы данных, касающиеся предпочтений пользователей для
небольших групп пользователей; или если имеются элементы UI, создание которых
достаточно ресурсоемко. Также используйте этот подход для ресурсоемких данных,
отображаемых пользователю, например, списков продуктов или сведений о
продуктах
Кэшируйте данные в бизнес-слое, если необходимо сохранять состояние сервиса,
бизнес-процесса или рабочего процесса; или если для обработки запросов от
уровня представления требуются относительно статические данные, создание
которых достаточно ресурсоемко.
Кэшируйте данные в слое доступа к данным при наличии коллекции входных
параметров для часто вызываемых хранимых процедур или небольших объемов
необработанных данных, возвращаемых часто выполняемыми запросами.
Рассмотрите варианты кэширования для типизированных наборов данных в слое
данных.
Кэшируйте в отдельную таблицу базы данных любые данные, для получения
которых требуется выполнение достаточно сложного и ресурсоемкого запроса. Этот
вариант кэширования поможет также обеспечить повышение производительности,
если требуется кэшировать очень большие объемы данных при реализации
механизма разделения на страницы.
Шаг 3 – Определение формата кэширования данных
Теперь, определившись с данными, которые необходимо кэшировать, и приняв решение о
месторасположении кэша, важно выбрать формат для кэшированных данных. При
кэшировании храните данные в формате, оптимизированном для предполагаемого
использования и не требующем дополнительной или повторной обработки или
преобразования. Этого правила следует придерживаться, если данные кэшируются в памяти,
если кэш не будет использоваться совместно разными процессами или компьютерами, если
нет необходимости перемещать кэшированные данные в разные участки памяти, и если
приходится кэшировать необработанные данные, такие как объекты DataSet, DataTable и Веб-
страницы.
Если необходимо хранить или передавать кэшированные данные, рассмотрите возможность
их сериализации. Сериализация кэшированных данных – хороший выбор для кэширования
данных на диск или для хранения состояния сеансов на отдельном сервере или базе данных
SQL Server. Это также хороший подход, если необходимо обеспечить совместное
использование кэша разными процессами или компьютерами, перемещать кэшированные
данные в разные участки памяти или кэшировать собственные объекты. Сериализация может
осуществляться с помощью механизма сериализации XML или механизма бинарной
сериализации. Механизм сериализации XML подойдет, если определяющим фактором
является возможность взаимодействия. Если основной упор делается на производительность,
используйте механизм бинарной сериализации.
Шаг 4 – Выработка подходящей стратегии управления кэшем
Необходимо определить соответствующую политику срока действия кэша и сброса кэша. И
удаление по истечении срока действия, и сброс данных являются стратегиями удаления
кэшированных данных из хранилища кэша. Отличаются они тем, что при сбросе могут
удаляться действительные данные для высвобождения памяти под более часто используемые
элементы, тогда как удаление данных по истечении срока их действия означает, что эти
данные стали недействительными. Проверьте возможности используемой базовой системы
кэширования, не все реализации кэша предлагают все возможные варианты.
Стратегия срока действия кэша должна обеспечивать, чтобы в кэше находились только
действительные данные и элементы. Политика срока действия может использовать как срок
действия по времени, так и срок действия по уведомлению:
При использовании политики срока действия по времени кэшированные данные
устаревают или становятся недействительными по прошествии определенного
интервала времени в абсолютных или относительных показателях. Такую политику
рекомендуется применять для часто меняющихся данных, если кэшированные
данные регулярно обновляются, или если кэшированные данные остаются
действительными лишь в течение определенного промежутка времени или до
определенного времени. Выбирая политику срока действия по времени, можно
остановиться на политике срока действия по абсолютному времени или по
скользящему временному интервалу. Политика срока действия по абсолютному
времени позволяет определять время жизни кэшированных данных через задание
времени истечения их срока действия. Политика срока действия по скользящему
временному интервалу определяет время жизни кэшированных данных путем
задания промежутка времени с момента последнего доступа к кэшированным
данным, через который они будут считаться устаревшими.
При использовании политики срока действия по уведомлению кэшированные
данные устаревают или становятся недействительными на основании уведомлений
от внутренних или внешних источников. Такая политика подойдет при работе с
нечасто меняющимися кэшированными данными, если кэшированные данные
обновляются через непостоянные промежутки времени, или если данные остаются
действительными до тех пор, пока не будут изменены внешними или внутренними
системами. Обычно в качестве источников уведомлений выступают модули записи
файлов на диск, события WMI, уведомления об изменениях в базе данных и
операции бизнес-логики. Поступление уведомления означает истечение срока
действия или устаревание всех соответствующих элементов кэша.
Стратегия сброса кэша должна обеспечивать эффективное использование хранилища, памяти
и других ресурсов. Стратегия сброса кэша может быть явной или в результате сборки мусора:
Для явного сброса кэша необходимо задать, когда элемент должен быть удален.
Такая политика используется, если требуется поддерживать сценарий удаления
поврежденных или устаревших кэшированных данных, если используются
хранилища, не поддерживающие сборки мусора, или при работе с кэшем на диске.
Для сборки мусора необходимо определить условия и набор эвристических правил,
согласно которым элемент должен быть удален в ходе сборки мусора. Эту политику
рекомендуется применять, если требуется автоматически активировать сборку
мусора при устаревании ресурсов системы, если требуется обеспечить
автоматическое удаление редко используемых или маловажных элементов из
кэша, или при работе с кэшем в памяти.
Рассмотрим общие правила сборки мусора:
Алгоритм вытеснения по давности использования (Least Recently Used)
обеспечивает удаление элементов, которые не использовались в течение
наибольшего периода времени.
Алгоритм вытеснения по частоте использования (Least Frequently Used)
обеспечивает удаление элементов, которые с момента загрузки использовались
реже всего.
При использовании алгоритма вытеснения по приоритетности (Priority) всем
кэшированным элементам присваиваются приоритеты, и сборка мусора
выполняется на основании этих приоритетов с сохранением элементов, имеющих
более высокий приоритет.
Шаг 5 – Выбор метода загрузки кэшированных данных
Правильный выбор способа наполнения кэша позволит увеличить производительность и
сократить время отклика приложения. Принимая решение о том, как будет заполняться кэш,
учитывайте, сколько данных должно быть доступно при запуске приложения или при исходной
загрузке кэша, а также то, какое влияние это будет иметь на время запуска и
производительность приложения. Например, можно выполнять предварительную загрузку
данных в кэш при запуске приложения или извлекать кэшированные данные, только когда они
запрашиваются. Загрузка данных в кэш при запуске приложения может сократить время
отклика приложения, но при этом увеличить время загрузки. С другой стороны, загрузка
данных в кэш только по необходимости способствует сокращению времени запуска
приложения, но может увеличить время отклика при первом обращении к этим данным.
При проектировании стратегии заполнения кэша может использоваться упреждающая или
реактивная загрузка:
Упреждающая загрузка обеспечивает извлечение всех данных приложения при его
запуске и их кэширование на весь период выполнения приложения. Упреждающая
загрузка подойдет для относительно статических данных, или если известны
заранее частота их обновления, время жизни и размер. Если размер данных
неизвестен, их загрузка может привести к истощению ресурсов системы.
Используйте этот вариант загрузки также, если в качестве источника кэшированных
данных предполагается медленная база данных, или данные извлекаются по
медленной сети или из ненадежного Веб-сервиса.
Реактивная загрузка обеспечивает извлечение данных при запросе приложением и
их кэширование для запросов в будущем. Реактивная загрузка подойдет для
относительно непостоянных данных, когда время жизни кэшированных данных
неизвестно, объем кэшированных данных велик и источник данных надежен и
всегда доступен.
Этапы проектирования стратегии управления исключениями
Надежная и тщательно продуманная стратегия управления исключениями может упростить
дизайн приложения и повысить безопасность и управляемость. Она будет способствовать
облегчению задачи по разработке приложения для разработчиков, снижению времени и
затрат на разработку. Приведенные далее рекомендации помогут правильно выработать
стратегию управления исключениями.
Шаг 1 – Выбор обрабатываемых исключений
При проектировании стратегии управления исключениями для приложения важно
определиться с тем, какие исключения требуется обрабатывать. Должны обрабатываться
исключения системы или приложения, такие как формируются при попытках доступа к
системным ресурсам пользователями, не имеющими для этого разрешений; и системные
сбои, возникающие из-за проблем с жестким диском, ЦП или памятью. Также необходимо
обозначить обрабатываемые исключения бизнес-логики, т.е. исключения, обусловленные
такими действиями, как нарушение бизнес-правил.
Шаг 2 – Выбор стратегии выявления исключений
Создаваемый дизайн должен обеспечивать единообразную обработку исключений по всему
приложению. Это сделает приложение более устойчивым к ошибкам, сократиться вероятность
возникновения несогласованного состояния. Структурированная обработка исключений
является средством для управления исключениями с помощью блоков try, catch и finally, их
своевременного выявления и соответствующего реагирования на них.
Перехватывайте выявленные исключения, только если необходимо собрать данные об
исключении для протоколирования, добавить в исключение некоторые значимые данные,
очистить ресурсы, используемые в блоке кода, или повторить операцию для выхода из
состояния исключения. Не перехватывайте исключения с последующей их передачей вверх по
стеку вызовов, если не собираетесь выполнять ни одну из вышеперечисленных задач.
Шаг 3 – Выработка стратегии распространения исключений
Рассмотрим стратегии распространения исключений. В зависимости от требований контекста
приложение может (и должно) использовать сочетание любых или всех этих стратегий:
Разрешить распространение исключений. Эта стратегия хороша тем, что не требует
сбора данных об исключении для протоколирования, добавления данных в
исключение, очистки каких-либо ресурсов в блоке кода или повтора операции для
выхода из состояния исключения. Вы просто позволяете исключению
распространяться вверх по стеку кода.
Перехват и повторное формирование исключений. При такой стратегии
исключение перехватывается, обрабатывается некоторым образом и повторно
формируется. Обычно в этом случае данные исключения остаются нетронутыми.
Применяйте эту стратегию, если требуется очищать ресурсы, протоколировать
данные исключения или выполнить попытку выхода из состояния ошибки.
Перехват, обертывание и формирование исключений. Эта стратегия обеспечивает
перехват универсальных исключений с последующей очисткой ресурсов или любой
другой соответствующей обработкой. Если не удается обработать ошибку,
исключение заключается в другое исключение, более уместное для вызывающей
стороны, и после этого формируется новое исключение для обработки кодом,
расположенным выше в стеке кода. Применяйте такую стратегию, если хотите
сохранить уместность исключения и/или обеспечить дополнительными сведениями
код, обрабатывающий исключение.
Перехват и аннулирование исключений. Эта стратегия является нерекомендуемой,
но может применяться в особых случаях. Исключение перехватывается, и
приложение продолжает выполняться в обычном порядке. В случае
необходимости, можно зарегистрировать исключение и выполнить очистку
ресурсов. Такая стратегия подходит для исключений системы, не оказывающих
влияния на другие операции, такие как исключения, формируемые при заполнении
журнала.
Шаг 4 – Выработка стратегии использования собственных исключений
Подумайте, существует ли необходимость в проектировании собственных исключений или
достаточно будет стандартных типов исключений .NET Framework. Не используйте
собственные исключения, если в иерархии исключений или в .NET Framework уже имеется
подходящее исключение. Но создавайте собственные исключения, если приложение должно
выявлять и обрабатывать специальную исключительную ситуацию, чтобы избежать
применения условной логики, или если необходимо включить дополнительные данные для
выполнения определенного требования.
Если все-таки приходится создавать собственные классы исключений, применяйте в них
стандартные конструкторы, включая конструктор сериализации, и обязательно заканчивайте
имя класса словом «Exception» (Исключение). Это важно для обеспечения интеграции со
стандартным механизмом исключений. Реализуйте собственное исключения путем
наследования от подходящего более общего исключения и его специализации соответственно
конкретным требованиям.
В общем, при проектировании стратегии управления исключениями вы должны создавать
иерархию исключений и организовывать собственные исключения в ее рамках. Это поможет
пользователям быстро анализировать и прослеживать возникающие проблемы. В собственных
исключениях должен быть указан слой, в котором было сформировано исключение,
компонент, в котором, возможно, возникло исключение, и тип сформированного исключения
(такой как исключение безопасности, бизнес-логики или системное исключение).
Храните иерархию исключений приложения в отдельной сборке, на которую может ссылаться
код приложения. Это поможет централизовать управление и развертывание классов
исключений. Также продумайте, как будет выполняться передача исключений через
физические границы, границы процессов или AppDomain. Классы .NET Framework Exception
поддерживают сериализацию. При проектировании собственных классов исключений
обеспечьте, чтобы они также поддерживали сериализацию.
Шаг 5 – Выбор соответствующих данных для сбора
Один из наиболее важных аспектов при обработке исключений – правильный выбор стратегии
сбора данных исключения. Перехватываемые сведения должны точно представлять условие
возникновения исключения. Также они должны быть значимыми и информативными для
аудитории. Можно выделить три категории аудитории: конечные пользователи, разработчики
приложения и операторы. На основании сценария и индивидуального контекста установите,
кому адресовано исключение.
Для конечных пользователей требуется осмысленное и хорошо представленное описание. При
сборе данных исключения для конечных пользователей позаботьтесь, чтобы они были поданы
в виде понятного пользователям сообщения, описывающего природу ошибки и
предлагающего пути восстановления после такой ошибки, если это возможно. Разработчикам
приложения необходимы более подробные сведения, которые помогут в диагностике
проблемы.
Разработчикам приложения необходимы данные о точном месте возникновения исключения в
коде, а также такие сведения, как тип исключения и состояние системы в момент
возникновения исключения. Операторам службы поддержки должна предоставляться
соответствующая информация, которая позволит им реагировать соответствующим образом и
предпринять необходимые шаги по восстановлению системы после ошибки. При сборе
данных исключения для операторов службы поддержки обеспечьте сведения, которые
помогут им найти людей, которых они должны уведомить об исключении, и информацию,
которую они должны будут передать для решения проблемы.
Независимо от целевой аудитории всегда полезно обеспечивать исчерпывающую
информацию об исключении. Сохраняйте эти сведения в файле журнала для последующей
проверки и анализа частоты возникновения исключений и их данных. По умолчанию должны
фиксироваться, как минимум, дата и время, имя компьютера, источник исключения и тип,
сообщение об исключении, данные о стеке и вызовах, доменное имя приложения, имя и
версия сборки, ID потока и сведения о пользователе.
Шаг 6 – Выработка стратегии протоколирования исключений
Существует ряд возможных вариантов протоколирования данных исключения. Следующие
основные соображения помогут сделать правильный выбор:
Используйте Windows Event Log (Журнал регистрации событий Windows) или
Windows Eventing 6.0, если приложение развернуто на одном компьютере, если
необходимо использовать существующие инструменты для просмотра журнала,
или если надежность является основным требованием.
Используйте SQL Database, если приложение развернуто на ферме или в кластере,
если необходимо обеспечить централизованное протоколирование, или если
требуется гибкость в структурировании и протоколировании данных исключения.
Используйте собственный файл журнала, если приложение развернуто на одном
компьютере, если необходима абсолютная гибкость выбора формата
протоколирования, или если хотите просто и легко реализовать хранилище журнала
регистрации. Контролируйте размер файла журнала, периодически очищая или
архивируя журнал, чтобы он не разрастался в размерах.
Выбирайте Message Queuing в качестве механизма доставки для передачи
сообщений об исключениях в точку их окончательного назначения, если
надежность является главным требованием, если приложения развернуты на
ферме или в кластере, или если требуется централизовать протоколирование.
В любом приложении может использоваться несколько из представленных вариантов в
зависимости от сценария и политики обработки исключений. Например, исключения
безопасности могут протоколироваться в Security Event Log, а исключения бизнес-логики – в
базу данных.
Шаг 7 – Выбор стратегии уведомления об исключениях
При выработке стратегии управления исключениями необходимо также принять решение о
стратегии уведомления. Часто в корпоративных приложениях только управления
исключениями и протоколирования не достаточно. Необходимо предусмотреть также
уведомления, чтобы обеспечить информирование о возникающих исключениях
администраторов и операторов. Для этого могут использоваться такие технологии, как события
WMI, электронные письма SMTP, текстовые сообщения SMS или другие системы уведомления.
Рассмотрите возможность использования внешних механизмов уведомления, таких как
системы мониторинга журналов или среды сторонних производителей, которые выявляют в
данных журнала условия возникновения ошибки и формируют соответствующие уведомления.
Такой подход рекомендуется, если требуется отделить систему мониторинга и уведомления от
кода приложений, оставив в приложениях только код протоколирования. Но если вы хотите
обеспечить немедленное уведомление без использования внешних систем мониторинга,
можно ввести в приложение специализированные механизмы уведомления.
Шаг 8 – Принятие решение об обработке необрабатываемых
исключений
Если исключение остается необработанным до последней точки или границы и нет
возможности восстановления после исключения перед возвращением управления
пользователю, приложение должно обработать это необработанное исключение. Для
необрабатываемых исключений требуется собрать необходимые сведения, записать их в файл
журнала или аудита, разослать все необходимые для этого исключения уведомления,
выполнить всю необходимую очистку и, наконец, передать информацию об ошибке
пользователю.
Не раскрывайте всех деталей исключения. Предоставьте пользователю понятное
универсальное сообщение об ошибке. Для клиентов без пользовательского интерфейса, таких
как Веб-сервисы, вместо детального исключения можно сформировать универсальное
исключение. Это предотвратит возможность разглашения данных системы конечному
пользователю.
Реализуйте стратегию управления исключениями, протоколирования и уведомления с
помощью Exception Handling Application Block (Блок обработки исключений) и Logging
Application Block (Блок протоколирования), созданных группой patterns & practices. Exception
Handling Application Block поддерживает ряд вариантов обработки исключений. Logging
Application Block может принимать, форматировать и отправлять сообщения и уведомления
журнала в различные журналы и другие точки назначения. Более подробно эти вопросы
рассматриваются в приложении F, «Enterprise Library от patterns & practices».
Этапы проектирования стратегии валидации ввода и данных
Приведенные далее рекомендации помогут правильно выработать стратегию валидации для
приложения. При проектировании валидации ввода и данных для приложения, прежде всего,
необходимо обозначить границы доверия и ключевые сценарии того, когда должна
проводиться валидация данных. Далее определяются данные, подлежащие валидации, и
место, где эта валидация должна выполняться. Также необходимо найти, как обеспечить
возможность повторного использования стратегии валидации при ее реализации. И, наконец,
определить соответствующую стратегию валидации для приложения.
Шаг 1 – Определение границ доверия
Границы доверия разделяют данные из доверенного источника и данные, к которым нет
доверия. Данные, находящиеся с одной стороны границы доверия, являются доверяемыми, и
с другой стороны границы располагаются не имеющие доверия данные. Чтобы понять, что
придется проверять, необходимо, прежде всего, выявить данные, пересекающие границы
доверия. Используйте валидацию ввода и данных на каждой границе доверия, чтобы
сократить угрозы безопасности, такие как межсайтовая атака внедрением сценариев и