Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ООП / ООП / ры_приложений_полная_книга.pdf
Скачиваний:
500
Добавлен:
18.02.2017
Размер:
7.08 Mб
Скачать

Слой доступа к данным

В слое доступа к данным Веб-приложения абстрагируйте логику, необходимую для доступа к базе данных. Использование отдельного слоя доступа к данным упрощает конфигурацию и обслуживание приложения, и также скрывает детали базы данных от остальных слоев приложения. Проектируйте объекты сущностей, которые могут заполняться слоем доступа к данным или использоваться для обновления источника данных, и применяйте объекты передачи данных (DTO) для взаимодействия с другими слоями и передачи данных между слоями.

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

Слой сервисов

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

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

Наконец, выполните требования по обеспечению возможности взаимодействия, выбирая соответствующие протоколы и механизмы транспортировки. Например, используйте ASMX для общего и WCF для более детального управления конфигурацией. Примите решение о том, будет ли интерфейс предоставлять методы SOAP, REST или оба типа методов. Более подробно сервисы рассматриваются в главе 9, «Рекомендации по проектированию слоя сервисов», и главе 18, «Взаимодействие и обмен сообщениями».

Вопросы тестирования и тестируемости

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

для того, чтобы обеспечить раннюю диагностику проблем и, таким образом, сократить затраты на обслуживание. Для обеспечения тестируемости:

Четко определяйте ввод и вывод слоев и компонентов приложения уже на этапе проектирования.

Используйте для слоя представления шаблоны отделения представления, такие как MVC или MVP. Это обеспечит возможность модульного тестирования логики представления.

Реализуйте бизнес-логику и рабочие процессы в отдельном бизнес-слое, что улучшит тестируемость приложения.

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

Выработайте эффективную стратегию протоколирования и трассировки, что позволит выявлять или диагностировать ошибки, которые в противном случае было бы сложно найти. Обеспечьте данные протоколирования и трассировки, которые могут использоваться средствами мониторинга или управления. Это поможет обнаруживать дефектный код при возникновении ошибок. Файлы журнала должны содержать сведения, которые можно использовать для воссоздания проблемы.

Вопросы выбора технологий

В ASP.NET модель ASP.NET Web Forms можно сочетать с широкой номенклатурой других технологий, включая ASP.NET AJAX, ASP.NET MVC, Silverlight и ASP.NET Dynamic Data. Примите во внимание следующие рекомендации:

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

Используйте ASP.NET и AJAX для создания приложений, обеспечивающих повышенные возможности взаимодействия с пользователем и фоновую обработку с меньшим количеством перезагрузок страниц.

Используйте ASP.NET и элементы управления Silverlight для создания приложений, которые включают насыщенное медиа-содержимое и расширенные возможности взаимодействия с пользователем.

При использовании ASP.NET позаботьтесь о предоставлении шаблонов страниц для реализации единообразного UI для всех страниц.

Используйте ASP.NET Dynamic Data для создания управляемого данными Вебприложения, страницы которого формируются на основании модели данных базовой базы данных.

При использовании разработки через тестирование или в случае необходимости обеспечить детализированное управление UI применяйте шаблон MVC и ASP.NET MVC. Это позволит четко отделить логику приложения и навигации от UI приложения.

Соседние файлы в папке ООП