Вопросы выбора технологий
Следующие рекомендации помогут правильно выбрать технологию и методики для реализации проектируемого приложения на основании его типа и предъявляемых к нему требований:
Если требуется обеспечить поддержку запросов и параметров, используйте объекты ADO.NET напрямую.
Если требуется поддерживать более сложные сценарии доступа к данным или упростить код доступа к данным, используйте Data Access Application Block (Блок доступа к данным) библиотеки Enterprise Library. Более подробно Enterprise Library
рассматривается в приложении F, «Enterprise Library от patterns & practices».
При создании управляемого данными Веб-приложения, страницы которого используют модель данных базовой базы данных, используйте технологию ASP.NET Dynamic Data (Динамические данные ASP.NET).
Если требуется работать с форматированными XML-данными, используйте классы пространства имен System.Xml и его дочерних пространств имен или Linq to XML (XLinq).
При создании пользовательского интерфейса с помощью ASP.NET рассмотрите возможность применения DataReader для доступа к данным, чтобы максимально увеличить производительность формирования визуального представления. Объекты DataReader идеально подходят для ситуаций, где необходимо только чтения и только движение вперед, в которых каждая строка обрабатывается быстро.
Для реализации доступа к SQL Server используйте классы пространства имен SqlClient ADO.NET, они обеспечат максимальную производительность.
Для реализации доступа к SQL Server 2008 используйте FILESTREAM, что обеспечит большую гибкость для хранения и доступа к BLOB-данным.
При проектировании объектно-ориентированного бизнес-слоя на основании шаблона Domain Model используйте O/RM-средства, такие как ADO.NET Entity Framework или инструментарий с открытым исходным кодом NHibernate (для получения более развернутой информации обратитесь в раздел Дополнительные источники в конце данной главы).
Руководство по выбору технологии доступа к данным приведено в главе 15, «Проектирование компонентов слоя доступа к данным». Технологии, доступные на платформе Microsoft, представлены в приложении С, «Матрица технологий доступа к данным».
Вопросы производительности
Производительность – это функция как дизайна слоя доступа к данным, так и дизайна базы данных. Для обеспечения максимальной пропускной способности при настройке системы
рассматривайте их вместе. При проектировании производительности руководствуйтесь следующими рекомендациями:
Используйте пул подключений и оптимизируйте производительность, исходя из результатов, полученных при моделировании нагрузочных сценариев.
Рассмотрите возможность настройки уровней изоляции для запросов к данным. Для приложения с высокими требованиями по пропускной способности специальные операции с данными могут выполняться на более низких уровнях изоляции, чем вся остальная транзакция. Комбинирование различных уровней изоляции может иметь негативное влияние на непротиворечивость данных, поэтому необходимо тщательно анализировать этот аспект для каждого отдельного случая.
Выполняйте пакетирование команд, чтобы сократить количество обращений к серверу базы данных.
Для нечасто меняющихся данных используйте оптимистическую блокировку. Это позволит сократить издержки на блокировку строк базы данных, в том числе и на подключение, которое должно оставаться открытым в течение всей блокировки.
В случае применения DataReader используйте последовательный поиск, это обеспечит большую производительность.
Вопросы безопасности
Слой доступа к данным должен обеспечивать защиту базы данных от попыток похищения или повреждения данных. Для различных частей источника данных должен предоставляться только необходимый уровень доступа. Также слой доступа к данным должен защищать механизмы, используемые для получения доступа к источнику данных. При проектировании системы безопасности руководствуйтесь следующими рекомендациями:
При работе с SQL Server используйте аутентификацию Windows с реализацией модели доверенной подсистемы безопасности. Подробно модель доверенной подсистемы безопасности рассматривается в главе 19, «Физические уровни и развертывание».
Шифруйте строки подключения в конфигурационных файлах, вместо того чтобы использовать системные или пользовательские DSN.
Для хранения паролей применяйте не шифрованную версию пароля, а хеш с шумом.
Требуйте, чтобы вызывающая сторона передавала данные удостоверения в слой доступа к данным для аудита.
Используйте параметризованные SQL-запросы и типизированные параметры, чтобы снизить риски безопасности и сократить шансы на успех атак с внедрением SQLкода. Не применяйте конкатенацию строк для построения динамических запросов на базе вводимых пользователем данных
Вопросы развертывания
При проектировании развертывания слоя доступа к данным архитектор ПО должен учесть производительность и вопросы безопасности среды производственной эксплуатации. При развертывании слоя доступа к данным руководствуйтесь следующими рекомендациями:
Если это не противоречит требованиям масштабирования и безопасности, размещайте слой доступа к данным на одном уровне с бизнес-слоем, это обеспечит лучшую производительность приложения.
Если требуется поддерживать удаленный уровень доступа к данным, улучшить производительность позволит применение протокола TCP.
Рассмотрите возможность размещения слоя доступа к данным на другом сервере, отличном от сервера базы данных. Физические характеристики сервера базы данных обычно оптимизированы для этой роли и редко соответствуют параметрам, являющимся оптимальными для слоя доступа к данным, поэтому размещение этих двух слоев физически на одном уровне, практически, безусловно приведет к снижению производительности приложения.
Этапы проектирования слоя доступа к данным
Правильный подход к проектированию слоя доступа к данным обеспечит сокращение времени на разработку и большее удобство обслуживания слоя доступа к данным после развертывания приложения. В этом разделе кратко представлен эффективный подход к проектированию слоя доступа к данным. Рассмотрим основные этапы проектирования слоя доступа к данным:
1.Создайте общий дизайн слоя доступа к данным. Выберите, с какой средой будете работать, greenfield или brownfield, и, исходя из этого, определите ограничения источника данных и соответствующие ограничения слоя данных. Кроме того, в случае необходимости доработки, проанализируйте, как новый код будет сосуществовать с источником данных в его текущем состоянии.
◦В сценарии с использованием среды greenfield вы имеете полный контроль над схемой, используемой источником данных. Ограничения обуславливаются самим источником данных.
◦В сценарии с использованием среды brownfield вы не обладаете контролем над схемами источника данных, и в его качестве может выступать все, что угодно, начиная от базы данных, до компонентов шлюза, используемых для взаимодействия с существующими компонентами. Необходимо понимать структуру и ограничения существующего бизнеса. Например, выясните, имеется ли заданное хранилище операционных данных или другие ограничения, которые помешают изменить существующую схему. Но, как правило, есть возможность добавлять новые таблицы или представления в существующую схему. Также определитесь, как будет осуществляться
взаимодействие со слоем данных: через Веб-сервисы или с помощью устаревшего приложения, использующего компоненты шлюза. В любом случае взаимодействие будет ограничено операциями, определенными в контракте Веб-сервиса или в интерфейсе, предоставляемом компонентами шлюза.
2.Выберите необходимые типы сущностей. Компоненты доступа к данным работают
ссущностями. Сущности используются для размещения и управления данными, используемыми приложением, и в них желательно включить весь необходимый код валидации. Также важно правильно выбрать тип и формат данных бизнессущностей, поскольку это определит выполнение требований по обеспечению возможности взаимодействия и сериализации. Руководство по выбору типов сущностей и типы, обычно используемые в бизнес-копмонентах и компонентах данных, можно найти в главе 13, «Проектирование бизнес-сущностей». При выборе формата данных обратите внимание на следующие аспекты:
◦Если требуется поддерживать сценарии без постоянного подключения в простых приложениях, выполняющих CRUD-операции, используйте объекты DataSet или отдельные DataTable. Самым распространенным подходом является применение ADO.NET. Это идеальный вариант при работе с существующим приложением, в котором уже используются ADO.NET. При проектировании нового приложения можно применять LINQ to Datasets для заполнения DataSet с помощью запросов LINQ.
◦Если к слою доступа к данным будут обращаться другие приложения или требуется обеспечить возможность взаимодействия с другими системами или платформами, используйте формат XML.
◦Если большое значение имеет удобство и простота обслуживания приложения, применяйте специальные бизнес-сущности. Для этого придется писать дополнительный код для сопоставления сущностей с операциями базы данных, но решения O/RM могут облегчить задачу разработчика. Для обеспечения большей гибкости используйте ADO.NET Entity Framework или другие O/RM-средства, такие как инструментарий с открытым исходным кодом NHibernate.
◦Реализуйте сущности, наследуя их от базового класса, который обеспечивает основную функциональность и инкапсулирует выполнение общих задач. Однако не перегружайте базовый класс ненужными операциями, что может понизить связность сущностей, унаследованных от этого базового класса, и негативно сказаться на удобстве обслуживания и производительности.
◦В проектируемых сущностях реализуйте взаимодействие с базой данных, полагаясь на компоненты логики доступа к данным. Обеспечьте централизованную реализацию всех политик доступа к данным и соответствующей бизнес-логики. Например, если бизнес-сущности выполняют прямой доступ к базам данных SQL Server, всем приложениям,