Однако модель провайдеров не идеальна. Хотя вы можете применять стандартные интерфейсы для взаимодействия с объектами Command и Connection, при создании их экземпляров вы должны знать специфичные для конкретного провайдера, строго типизированные классы, которые придется использовать (такие как SqlConnection). Это ограничение усложняет построение других инструментов или дополнений, применяющих ADO.NET. Например, из главы 9 вы узнаете о новых элементах управления источников данных ASP.NET, которые позволяют создавать привязанные к данным страницы без написания даже строки кода. Чтобы использовать эту функциональность, вам понадобится способ управления данными для создания необходимых объектов ADO.NET, работающих "за кулисами". Ранее не было возможности реализовать это средство без серьезных ограничений .NET 1.x.
.NET 2.0 решает эту проблему и добавляет усовершенствованную поддержку для написания независимого от провайдера кода (кода, который может работать с любой базой данных). Секрет — в новой модели фабрик.
На заметку! Независимый от провайдера код удобен для построения специализированных компонентов. Это также может иметь смысл, если вы ожидаете в будущем перехода на другую базу данных либо не вполне уверены в том, какая база данных будет использоваться в финальной версии приложения. Однако это имеет и свои недостатки. Независимый от провайдера код не может воспользоваться некоторыми специфичными для конкретного провайдера свойствами (такими как XML-запросы в SQL Server), к тому же их сложнее оптимизировать. По этим причинам он не часто используется в широкомасштабных профессиональных Web-приложениях.
Основная идея модели фабрик заключается в том, что вы используете единственный объект-фабрику для создания всех прочих необходимых специфичных для провайдера объектов. Затем вы можете взаимодействовать с этими специфичными для провайдера объектами полностью обобщенным способом — через набор базовых классов.
Фабрика классов сама по себе специфична для провайдера. Например, провайдер данных SQL Server включает класс по имени System.Data.SqlClient.SqlClientFactory. Провайдер Oracle использует System.Data.OracleClient.OracleClientFactory. На первый взгляд может показаться, что это исключает написание независимого от провайдера кода. Однако на самом деле существует полностью стандартизованный класс, который предназначен для динамического нахождения и создания необходимой фабрики. Это класс System.Data.Common.DbProviderFactories. Он представляет статический метод GetFactory(), возвращающий фабрику на основе имени провайдера.
Например, вот как выглядит код, использующий DbProviderFactories для получения SqlClientFactory:
string factory = "System.Data.SqlClient";
DbProviderFactory provider = DbProviderFactories.GetFactory(factory);
Несмотря на то что класс DbProviderFactories возвращает строго типизированный объект SqlClientFactory, вы не должны трактовать его как таковой. Вместо этого ваш код обращается к нему как к экземпляру DbProviderFactory.
предыдущая следующая страница оглавление
332