Интерфейс прикладного программирования хранилища для общей платформы данных

Интерфейс прикладного программирования хранилища для общей платформы данных

Иллюстрации

Показать все

Реферат

Настоящая заявка испрашивает приоритет по предварительной заявке на выдачу патента США с серийным номером 60/657,522, озаглавленной «ИПП ХРАНИЛИЩА ДЛЯ ОБЩЕЙ ПЛАТФОРМЫ ДАННЫХ», поданной 28 февраля 2005. Эта заявка связана с предварительной заявкой на выдачу патента США с серийным номером 60/657,556, озаглавленной «ПЛАТФОРМА ДЛЯ УСЛУГ ПО ПЕРЕДАЧЕ ДАННЫХ ПО НЕРАВНОПРАВНЫМ ПРИКЛАДНЫМ СТРУКТУРАМ», поданной 28 февраля 2005, заявкой на выдачу патента США с серийным номером 11/171,905, озаглавленной «ПЛАТФОРМА ДЛЯ УСЛУГ ПО ПЕРЕДАЧЕ ДАННЫХ ПО НЕРАВНОПРАВНЫМ ПРИКЛАДНЫМ СТРУКТУРАМ», поданной 30 июня 2005, предварительной заявкой на выдачу патента США с серийным номером 60/657,295, озаглавленной «МОДЕЛЬ ДАННЫХ ДЛЯ ОБЪЕКТНО-ОТНОСИТЕЛЬНЫХ ДАННЫХ», поданной 28 феврале 2005, и заявкой на выдачу патента США (номер дела поверенного MSFTP974USA), озаглавленной «МОДЕЛЬ ДАННЫХ ДЛЯ ОБЪЕКТНО-ОТНОСИТЕЛЬНЫХ ДАННЫХ». Содержание вышеупомянутых заявок включено в настоящие материалы посредством ссылки.

Уровень техники

Данные стали важным активом в почти каждом приложении, является ли оно структурой Специализированного Делового (СПД) приложения, используемой для просмотра продуктов и генерирования заказов или приложением Личного Информационного Управления (ЛИУ) конечного пользователя, используемым для планирования встреч с людьми. Приложения выполняют как операции доступа к данным/манипуляции данными, так и операции организации данных по данным приложения. Обычные операции приложения обращаются с запросом к совокупности данных, выбирают набор результата, исполняют некоторую логику приложения, которая изменяет состояние данных, и, в завершении, сохраняют данные на носителе данных.

Традиционно, клиент/серверные приложения отсылали запрос и действия по перманентным объектам к системам управления базой данных (СУБД), используемой в ярусе данных. Если имеется логика, интегрированная по данным, ее кодируют, как сохраненные процедуры в системе базы данных. Система базы данных оперирует данными в выражении таблицами и строками, и приложения, в ярусе приложений, оперируют данными в выражении объектами языка программирования (например/ Классами и Структурами). Несоответствие в услугах по обработке данных (и механизмах) в приложении и ярусах данных было терпимо в клиент/серверных системах. Однако, с появлением сетевой технологии (и Сервис-Ориентированной Архитектуры) и с более широким принятием серверов приложений, приложения становятся многоярусными, и, что еще более важно, данные теперь присутствуют в каждом ярусе.

В такой ярусной прикладной архитектуре данные обрабатывают во множестве ярусов. Кроме того, в связи с аппаратными усовершенствованиями в адресуемости и большими объемами памяти, больше данных становятся резидентными. Приложения также имеют дело с различными типами данных, такими, как объекты, файлы и XML-данные (XML, РЯР, Расширяемый Язык Разметки), например.

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

Раскрытие изобретения

Далее представлено упрощенное раскрытие, предназначенное для обеспечения базового понимания некоторых аспектов раскрытого нового решения. Это раскрытие не является обширным обзором и не предназначено для определения ключевых/критических элементов или очерчивания их объема. Единственная его задача состоит в том, чтобы представить некоторые понятия в упрощенной форме, в качестве вводной части для более подробного описания, которое представлено далее.

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

В другом аспекте ИПП включает в себя пять основных классов. Класс TableSet может быть выработан из схемы модели данных и обеспечивает доступ со строгим контролем типов к таблицам, заданным в схеме. Класс StorageDomain определяет хранилище, по которому работают остальные классы. Класс StorageContext обеспечивает контекст для сеанса. Класс StorageContext определяет область для управления идентификационными данными, отслеживания изменений и обработки конфликтов при совмещении операций с методами для обновления или сохранения изменений в объектах в текущем контексте. Классы StorageSearcher используют для построения компонуемых основывающихся на объектах запросов к хранилищу данных. Класс StorageView обеспечивает обширное представление приложения по набору результатов. Классы StorageView поддерживают операции, такие как фильтрация, сортировка, прокрутка, группирование, секционирование, растяжение/свертывание разделов и т.д.

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

Краткое описание чертежей

Фиг.1 - интерфейс прикладного программирования (ИПП) хранилища платформы данных, в соответствии с новым аспектом.

Фиг.2 - методология, обеспечивающая ИПП хранилища, в соответствии с раскрытым аспектом.

Фиг.3 - более детальная схема компонента обобщенного доступа к данным ИПП хранилища.

Фиг.4 - методология обеспечения ИПП хранилища для модели данных.

Фиг.5 - методология экспонирования типов табличного набора.

Фиг.6 - методология обеспечения функциональных возможностей WinFS в ИПП.

Фиг.7 - методология представления класса в хранилище.

Фиг.8 - методология инкапсуляции подключения между клиентом и одним или несколькими хранилищами.

Фиг.9 - методология формирования запросов к хранилищу.

Фиг.10 - методология просмотра по набору результатов.

Фиг.11 - методология обеспечения начального представления данных по результатам.

Фиг.12 - методология расширения класса записи хранилища.

Фиг.13 - система, которая использует ИПП хранилища для общей платформы данных.

Фиг.14 - структурная схема компьютера, пригодного для выполнения раскрытой архитектуры.

Фиг.15 - схематичное структурное представление приводимой в качестве примера вычислительного окружения.

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

В контексте использования в настоящей заявке термины «компонент» и «система» предназначены для того, чтобы относиться к связанному с компьютером объекту, т.е. аппаратному обеспечению, совокупности аппаратного и программного обеспечения, программному обеспечению или программному обеспечению в процессе его исполнения. Например, компонент может быть, но без ограничения только этим, процессом, исполняемым процессором, процессором, накопителем на жестком диске, множественными накопителями для хранения (оптическим и/или магнитным носителем данных), объектом, исполняемым файлом, потоком управления, программой и/или компьютером. Как в порядке иллюстрации, как приложение, исполняемое на сервере, так и сервер может быть компонентом. Один или несколько компонентов могут постоянно находиться в процессе и/или потоке управления, и компонент может быть локализован на одном компьютере и/или распределен между двумя или большим числом компьютеров.

Тогда как некоторые способы отображения информации пользователям показаны и описаны в отношении определенных фигур, как моментальных снимков экрана, для специалистов в данной области техники очевидным будет, что могут быть использованы различные другие альтернативы. Термины «экран», «web-страница» и «страница», как правило, использованы здесь взаимозаменяемо. Страницы или экраны сохраняют и/или передают как описания дисплейного устройства, как графические интерфейсы пользователя или другие представления информации на экране (персонального компьютера, ПЦА (PDA), мобильного телефона или другого подходящего устройства, например), где компоновка и информация или содержание, подлежащие отображению в странице сохраняют в памяти, базе данных или другом средстве хранения.

Новая общая платформа данных (CDP, ОПД) состоит из общей модели общих данных (CDM, ОМД), которая описывает объекты и как они связаны, и долговременного хранилища и услуг для работы с представлениями этих объектов «в памяти». ОПД обеспечивает новую платформу для работы с долговременными данными, как объектами приложений. ОПД включает в себя новый интерфейс прикладного программирования (ИПП), который выполнен специально под нижележащие модель данных и услуги, определенные как часть платформы. Функциональные возможности ОПД экспонируются через набор классов. Определение этих классов, включая их общедоступные члены (например, методы и свойства), включает в себя ИПП для работы с объектами в ОПД.

Обратимся вначале к Фиг.1, на которой представлен ИПП 100 хранилища платформы 102 данных (например, ОПД) в соответствии с новым аспектом. ИПП 100 обеспечивает интерфейс программирования для приложений, используя платформу данных (например, ОПД) в форме классов, интерфейсов и статических функций поддержки. Интеграция языка программирования базы данных (например, операторы последовательности С#) также представляет собой часть этого уровня ИПП. В поддержку этого ИПП 100 включает в себя компонент классов данных 104 ОМД, который является набором канонических, независимых от приложений классов, которые экспонируют концепты ОМД, такие как Сущность (Entity), Отношение (Relationship), Расширение (Extension) и т.д. Компонент 106 обобщенного доступа к данным обеспечен, как часть ИПП 100, чтобы экспонировать хранилища, сеансы, транзакции (например, StorageContext), услуги запроса (например, StorageSearcher) и услуги СООУ (например, SaveChanges). Услуги СООУ (Создать, Отыскать, Обновить и Удалить, CRUD) представляют собой основные процессы, которые применены к данным. ИПП 100 также включает в себя компонент 108 классов доменных данных, которые являются специфическими для конкретного приложения/инфраструктуры классами Контакт (Contact), Сообщение (Message), Заказы на Поставку (PurchaseOrders), которые соответствуют ОМД, но экспонируют доменно-ориентированные свойства и поведения.

На Фиг.2 представлена методология, обеспечивающая ИПП хранилища в соответствии с раскрытым аспектом. Несмотря на то, что для целей простоты объяснения одна или несколько представленных в настоящих материалах методологий, например, в виде блок-схемы или структурной схемы, показаны и описаны, как последовательность действий, понятным и очевидным является, что новое решение не ограничено порядком действий, поскольку некоторые действия могут, в соответствии с ним, происходить в ином порядке и/или одновременно с другими действиями, иными, чем показанные и описанные здесь. Например, для специалистов в данной области техники будет понятным и очевидным, что методология может альтернативно быть представлена как ряд взаимосвязанных состояний или событий таких, как в диаграмме состояния. Более того, для осуществления методологии в соответствии с новым решением могут потребоваться не все представленные действия. На 200 получают ИПП хранилища. На 202 ИПП определяет класс для запроса данных. На 204 ИПП определяет класс для извлечения данных. На 206, ИПП определяет класс для навигации по данным. На 208 ИПП определяет класс для модификации данных. На 210, ИПП определяет класс для сохранения данных.

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

ИПП 300 хранилища состоит из следующих основных классов и на Фиг.3 представлены отношения между StorageDomain, StorageContext, TableSet, StorageSearcher и StorageView. В поддержку этих основных классов могут быть определены дополнительные классы.

TableSet - Класс TableSet может быть выработан из схемы модели данных и обеспечивает доступ со строгим контролем типов к определенным в схеме таблицам. Экземпляр TableSet заключает в себе один или несколько экземпляров StorageContext и использует основной класс StorageContext и ассоциированный класс StorageDomain для запроса, навигации и обновления объектов. К выработанному классу TableSet можно добавить дополнительные методы для функциональных возможностей, специфических для конкретной схемы или специфических для конкретной инфраструктуры.

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

StorageContext - класс, который обеспечивает контекст для сеанса. Класс StorageContext определяет область для управления идентификационными данными, отслеживания изменений и обработки конфликтов при совмещении операций с методами для обновления или сохранения изменений в объектах в текущем контексте. Класс StorageContext использует Класс StorageDomain для связи с хранилищем (например, при обновлении данных или сохранении изменений). StorageContext может быть использован непосредственно или в связке с TableSet.

StorageSearcher - Классы StorageSearcher используются для построения компонуемого, основанного на объектах запроса к хранилищу данных. Класс StorageSearcher вырабатывает класс StorageExpression, который исполняется посредством StorageDomain, обычно в StorageContext. StorageSearcher поддерживает перечисление результатов однонаправленным поточным образом или построение обширного прокручиваемого StorageView.

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

Обратимся теперь к Фиг.4, на которой представлена методология обеспечения ИПП хранилища для модели данных. На 400 получают платформу данных (например, ОПД) для использования с хранилищем данных. На 402 обеспечивают ИПП, который включает в себя базовые классы, которые представляют концепты ОМД, такие как, например, сущность, отношение, расширение. Нижележащие функциональные возможности платформы данных могут быть экспонированы вышележащим приложениям и инфраструктурам приложений через общие классы данных ОМД, определенные в ИПП по предмету изобретения. На 404 обеспечивают класс, который определяет хранилище данных, по которому работают другие классы ИПП. На 406 обеспечивают класс, который используют для формирования основанных на объектах запросов к хранилищу данных. На 408 обеспечивают класс, который задает контекст сеанса и включает в себя управление идентификационными данными, отслеживание изменений, обработку конфликта и т.д. На 410 обеспечивают класс, который формирует из схемы и обеспечивает доступ со строгим контролем типов к таблицам схемы. На 412 обеспечивают класс, который обеспечивает просмотр набора(наборов) результатов. На 414 определяют набор специфических для конкретного домена классов для того, чтобы представлять конкретные сущности и отношения, описанные экземпляром схемы ОМД.

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

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

Класс WinFSDomain. Пример StorageDomain относительно хранилища WinFS может выглядеть следующим образом:

Конструктор WinFSDomain может взять информацию для определения хранилища и области в пределах хранилища, например, посредством совместно используемого имени, соответствующего СУН (соглашению об универсальном назначении имен, UNC). В качестве альтернативы, заданный по умолчанию конструктор может использовать заданную по умолчанию информацию хранилища, например, к корню заданного по умолчанию хранилища. СУН представляет собой стандарт для идентификации серверов, принтеров и других ресурсов в сети, который берет свое начало в семействе UNIX. В пути СУН используются двойные наклонные черты. вправо или наклонные черты влево, которые предшествуют имени компьютера.

Класс SqlStorageDomain. Пример StorageDomain относительно реляционного хранилища (например, базы данных SQL) может выглядеть следующим образом:

Конструктор SqlStorageDomain может взять информацию соединения, например, в форме строки подключения, содержащий соединение и информацию сопоставления, или поименованной конфигурации, содержащей такую информацию. В качестве альтернативы конструктор может взять объект подключения совместно с информацией сопоставления в виде файла или объекта сопоставления, который использует стандартный интерфейс сопоставления. В качестве альтернативы, заданный по умолчаник конструктор может использовать заданное по умолчанию подключение или информацию сопоставления, например, из файла конфигурации.

На Фиг.5 представлена методология экспонирования типов табличного набора. На 500 получают базовый класс для типов таблицы. Класс TableSet используют как базовый класс для типов табличного набора. Экземпляры этого типа могут также быть созданы и использованы непосредственно приложением, если это желательно. Базовый тип TableSet имеет следующие члены:

public class TableSet: Idisposable

TableSet обычно конструируют с именем набора таблиц в Схеме (Schema). В качестве альтернативы набор таблиц в схеме может быть определен посредством альтернативного механизма, например посредством присваивания имен по умолчанию, файла конфигурации и т.д. StorageContext может быть обеспечен для TableSet, чтобы ассоциировать TableSet с существующим StorageContext. В качестве альтернативы StorageDomain может быть обеспечен для TableSet, чтобы ассоциировать TableSet с StorageDomain. В качестве еще одной альтернативы TableSet может быть обеспечен общий менеджер состояний.

На 502 может быть обеспечен метод SaveChanges для сохранения объектов данных, ассоциированных с табличным набором. Может быть также обеспечена асинхронная версия этого метода. На 504, может быть обеспечен метод GetTable для конструирования и выдачи объекта, представляющего таблицу в схеме (например, Table<T>), на основании предоставленного имени. На 506 может быть обеспечен метод GetTableSetReference для выдачи TableSetReference.

На Фиг.6 представлена методология обеспечения функциональных возможностей WinFS в ИПП по предмету нового решения. На 600 применяют класс для функциональных возможностей WinFS. Класс WinFSData может быть получен в качестве производного от класса TableSet, для обеспечения специфических для WinFS функциональных возможностей. Класс WinFSData имеет следующие члены:

Конструктор WinFSData может быть сконструирован с существующим StorageContext или может создать StorageContext с использованием определенной информации (такой как совместно используемый ресурс СУН) или заданной по умолчанию информации (например, корня заданного по умолчанию хранилища). Дополнительно, Имя (Name) табличного набора может быть задано для ассоциирования класса WinFSData с конкретным поименованным экземпляром табличного набора.

На 602 может быть обеспечен метод GetRootItem, для выдачи корня домена. Может быть также обеспечена асинхронная версия этого метода. На 604 может быть обеспечен метод GetItemByPath для выдачи элемента заданного его путем. Может быть также обеспечена асинхронная версия этого метода.

На 606 могут быть обеспечены свойства Items, ItemExtensions и ItemFragments для выдачи объектов, представляющих таблицы Items, ItemExtensions, и ItemFragments таблицы. На 608 может быть обеспечено свойство Link для выдачи объекта, представляющего таблицу Links. На 610 обеспечивают методы копирования, перемещения и удаления элементов. Может быть обеспечен метод Copyltem для копирования заданного элемента в другое местоположение в хранилище. Может быть обеспечен метод Moveltem для перемещения заданного элемента в пределах хранилища. Метод Deleteltem обеспечивает удаление заданного элемента из хранилища. На 612 обеспечивают методы для импорта и экспорта элементов. Может быть обеспечен метод Exportltem для экспорта заданного элемента из хранилища. Может быть обеспечен метод Importltem для импорта заданного элемента в хранилище. Также могут быть обеспечены асинхронные версии метода Copyltem, метода Moveltem, метода Deleteltem, метода Exportltem и метода Importltem.

На Фиг.7 показана методология представления класса в хранилище. На 700, задают класс, который представляет экстент в хранилище. Класс Table<Т> используют для представления экстента в хранилище. Класс Table<Т> может содержать методы добавления или удаления объектов в экстенте, а также для построения StorageSearcher по содержимому экстента.

Класс Table<Т> может быть создан с информацией, которая задает StorageContext или StorageDomain, наряду с именем соответствующей таблицы в схеме. На 702 может быть обеспечено свойство Context для выдачи StorageContext, ассоциированного с классом Table<Т>. На 704 может быть обеспечено свойство Domain для выдачи StorageDomain, ассоциированного с классом Table<T>. На 706 может быть экспонировано свойство Searcher для выдачи StorageSearcher по соответствующей таблице в хранилище. На 708 обеспечиваются методы добавления, удаления и очистки объектов. Метод Add может быть экспонирован для того, чтобы добавлять объект в таблицу. Метод Remove может быть экспонирован для того, чтобы определять объект, который будет удален из таблицы. Метод Clear может быть экспонирован для того, чтобы очищать таблицу. На 710 метод Contains может быть экспонирован для того, чтобы выдать, содержит или нет таблица заданный объект. На 712 метод Count может быть экспонирован для того, чтобы задавать общее количество объектов в таблице. На 714 обеспечивают метод, который копирует объекты в таблицу. На 716 обеспечивают свойство, которое экспонирует то, является ли таблица доступной только для чтения. Метод СоруТо может быть экспонирован для того, чтобы копировать заданные объекты в таблицу. Свойство IsReadOnly может быть экспонировано для того, чтобы выдать то, действительно ли в отношении таблицы может быть выполнено добавление или удаление.

На Фиг.8 представлена методология инкапсуляции подключения между клиентом и одним или несколькими хранилищами. Дополнительно, класс определяет контекст сеанса, область для управления идентификационными данными, отслеживания изменений и обработки конфликтов при совмещении операций. Класс StorageContext инкапсулирует соединение между клиентом и одним или несколькими хранилищами и представляет собой шлюз для операций СООУ (Создать, Читать, Обновить и Удалить).

StorageContext конструируют при наличии StorageDoraain, который обеспечивает информацию хранилища. В качестве альтернативы, StorageContext может быть создан без StorageDomain и получить информацию хранилища из заданного по умолчанию источника, такого как файл конфигурации.

На 802 обеспечивают метод, который выдает объект по ключу. Метод GetObjectByKey может быть обеспечен для выдачи объекта в пределах StorageContext, ассоциированного с конкретным ключом. Этот метод в качестве альтернативы может быть развернут в отдельный объект StateManagement. Асинхронная версия этого метода может также быть обеспечена. На 804 может быть обеспечен метод GetObjectKey для выдачи ключа, ассоциированного с конкретным объектом в StorageContext. Этот метод может в качестве альтернативы быть развернут в отдельный объект StateManagement. На 806 может быть обеспечен метод SaveChanges для сохранения, добавления, удаления или модификации объекта в StorageContext. Также может быть обеспечена асинхронная версия этого метода.

На 808 может быть обеспечен метод Refresh для обновления объектов в StorageContext текущими значениями хранилища. Может быть задан явный набор объектов для обновления, например, посредством перечислителя или как параметры. Дополнительные варианты могут быть определены для управления тем, как обрабатывать конфликты изменений. Также может быть обеспечена асинхронная версия этого метода. На 810 метод Add может быть обеспечен для ассоциирования нового объекта с StorageContext. Этот метод может в качестве альтернативы быть развернут в отдельный объект StateManagement. На 812 может быть обеспечен метод MarkForDeletion для помечания объекта в StorageContext, который подлежит удалению при вызове SaveChanges. Этот метод в качестве альтернативы может быть развернут в отдельный объект StateManagement. На 814 может быть обеспечено свойство StorageDomain для выдачи StorageDomain, ассоциированного с StorageContext.

На Фиг.9 представлена методология формирования запросов к хранилищу. На 900 определяют базовый класс для формирования запросов к хранилищу. Класс StorageSearcher используют для формирования компонуемых основанных на объектах запросов к хранилищу. StorageSearcher вырабатывает StorageExpression, который исполняется посредством StorageDomain, обычно в пределах StorageContext. StorageSearcher поддерживает результаты перечисления однонаправленным поточным образом или путем построения обширного прокручиваемого StorageView.

StorageSearcher может быть сконструирован с StorageContext или StorageDomain для задания контекста или хранилища, с которым связан StorageSearcher. Дополнительно, выражение запроса может быть задано так, чтобы инициализировать StorageSearcher либо как строку, либо как дерево объектов StorageExpression.

На 902 может быть обеспечен метод Query для создания нового StorageSearcher, который инкапсулирует произвольное выражение запроса. На 904 обеспечивают методы фильтрования. Метод Filter может быть обеспечен для конструирования нового StorageSearcher, который инкапсулирует фильтр по результатам запроса, которые вырабатывает средство поиска по входным данным (входной искатель). Может быть обеспечен метод FilterByType для конструирования нового StorageSearcher, который инкапсулирует фильтр по результатам запроса, которые вырабатывает входной искатель. Может быть обеспечен метод TreatAsType для конструирования нового StorageSearcher, который обрабатывает результаты запроса, которые вырабатывает входной искатель, как иной тип.

На 906 обеспечивают методы Sort, Project, Group и Union. Метод Sort может быть обеспечен для конструирования нового StorageSearcher, который инкапсулирует сортировку результатов запроса, вырабатываемых входным искателем. Метод Project может быть обеспечен для конструирования нового StorageSearcher, который инкапсулирует проекцию результатов запроса, вырабатываемых входным искателем. Метод Group может быть обеспечен для конструирования нового StorageSearcher, который инкапсулирует группировку результатов запроса, которые вырабатывает входной искатель. Метод Union может быть обеспечен для конструирования нового StorageSearcher, который инкапсулирует объединение результатов запроса, которые вырабатывают два входных искателя. Вышеупомянутое представляет собой только примеры, которые не должны рассматриваться как ограничивающие. Дополнительно могут быть обеспечены методы StorageSearcher для представления дополнительных операций запроса. Другими словами, операции запроса могут быть экспонированы как методы класса StorageSearcher, который выдает новые StorageSearchers.

На 908 может быть обеспечен метод GetEnumerator для выдачи перечислителя, который может быть использован для доступа к результатам запроса. Может быть также обеспечена асинхронная версия этого метода. На 910 обеспечиваются методы, которые выдают первый результат запроса. Могут также быть обеспечены асинхронные версии этих методов. Может быть обеспечен метод GetFirst для выдачи первого результата. Может также быть обеспечена асинхронная версия этого метода. Может быть обеспечен метод GetCount для выдачи подсчета результатов. Может также быть обеспечена асинхронная версия этого метода. На 912 может быть обеспечен метод CreateView для создания StorageView из запроса StorageSearcher. Метод CreateView может принять StorageViewDefinition с дополнительными опциями или без них для задания информации, специфической для конкретного просмотрового вида.

Класс StorageRecord используется как тип результата искателя, когда по запросу выдаются данные, которые не соответствуют никакому конкретному типу, определенному приложением. Например, результат операции Project или Group является совокупностью объектов StorageRecord.

На Фиг.10 представлена методология рассмотрения по набору результатов. На 1000 обеспечивают класс для просмотра результатов. Класс StorageView обеспечивает обширный просмотровый вид приложения по набору результатов. StorageView поддерживает такие операции, как фильтрация, сортировка, прокрутка, группировка, секционирование, растяжение/свертывание разделов и т.д.

Ha 1002 может быть обеспечен метод CopyDefinition для создания нового экземпляра StorageViewDefinition. Может быть обеспечен метод ApplyDefinition для применения заданного StorageViewDefinition к текущему StorageView. Также может быть обеспечена асинхронная версия этого метода. На 1004 обеспечивают методы для нахождения записей, выдачи подсчетов записей и текущей записи. Может быть обеспечен метод FindRecord для обнаружения StorageViewRecord в текущем StorageView, в соответствии с заданным фильтром, относительно заданной позиции или закладки. Может также быть обеспечена асинхронная версия этого метода. Метод Count может быть обеспечен для выдачи количества записей в текущем StorageView. Может также быть обеспечена асинхронная версия этого метода. Метод Current может быть обеспечен для выдачи текущего StorageViewRecord в пределах StorageView.

На 1006 может быть обеспечено индексированное средство доступа (например, this[]) для выдачи StorageViewRecord для данной Bookmark. Может также быть обеспечена асинхронная версия этого метода. На 1008 обеспечивают методы для перемещения позиции и обновления просмотрового вида. Может быть обеспечен метод MoveCurrentPosition для перемещения текущей позиции в пределах StorageView в соответствии с заданной позицией или закладкой и смещением. Может также быть обеспечена асинхронная версия этого метода. Может быть обеспечен метод Refresh для обновления данных в статическом StorageView текущими значениями из хранилища. Может также быть обеспечена асинхронная версия этого метода. На 1010, обеспечивают методы получения закладок и двоичного их представления. Может быть обеспечен метод GetBookraarkFroraBinary для получения закладки из постоянного двоичного представления. Может быть обеспечен метод GetBinaryFromBookmark для получения постоянного двоичного представления из Bookmark.

На 1012 обеспечивают методы для растяжения, свертывания разделов, уровней и полей. Может быть обеспечен метод CollapseAllSections для свертывания всех разделов, определенных в пределах StorageView. Может также быть обеспечена асинхронная версия этого метода. Может быть обеспечен метод ExpandAllSections для расширения всех разделов, определенных в пределах StorageView. Может также быть обеспечена асинхронная версия этого метода. Может быть обеспечен метод ExpandSectionLevel для растяжения всех разделов, вплоть до и включая заданный уровень. Может также быть обеспечена асинхронная версия этого метода.

На 1014 обеспечивают метод для расширения полей записей. Может быть обеспечен метод SetExtendedFields для того, чтобы задать расширенные поля, ассоциированные с набором StorageViewRecords. На 1016 обеспечивают методы для сохранения и загрузки состояния растянутых разделов. Может быть обеспечен метод LoadSectionExpandState для загрузки состояния, определяющего набор разделов, которые растянуты. Может также быть обеспечена асинхронная версия этого метода. Может быть обеспечен метод SaveSectionExpandState для того, чтобы сохранять состояние, задающее набор разделов, которые растянуты. StorageView может экспонировать событие ViewChanged для уведомления средства прослушивания, когда StorageView изменится.

На Фиг.11 показана методология представления начального просмотрового вида данных по результатам. На 1100 обеспечивают класс, который определяет начальный просмотровый вид данных. Класс StorageViewDefinition определяет начальный просмотровый вид данных по результатам, определенным посредством StorageSearcher.

}

На 1102 может быть обеспечено свойство Sort для получения или установки критериев сортировки для StorageView. На 1104 обеспечивают свойства для изменения и растяжения разделов. Свойство Sections может быть обеспечено для изменения списка Sections, определенных в StorageView. Может быть обеспечено свойство SectionExpandLevel для растяжения разделов вплоть до и включая заданный уровень. На 1106 обеспечивают свойство и метод для операций фильтрации. Свойство Filter может быть экспонировано для того, чтобы фильтровать StorageView для экспонирования только StorageViewRecords, соответствующих заданному условию фильтрации. Метод SetFilter может бы