Введение в ObjectSpaces

}МетодОписаниеBeginTransaction, Commit, RollbackУправление транзакциями. Стоит обратить внимание, что метод Rollback не откатывает изменения в сохраняемых объектах, поэтому возможны ситуации, когда

Введение в ObjectSpaces

Информация

Компьютеры, программирование

Другие материалы по предмету

Компьютеры, программирование

Сдать работу со 100% гаранией

Введение в ObjectSpaces

Тимофей Казаков (TK)

Сохраняемые объекты

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

В .NET Framework существуют готовые средства для работы с сохраняемыми объектами, есть возможность сохранять состояние объектов в двоичном виде с использованием BinaryFormatter или XML-формате с использованием XmlSerializer. Все эти средства предоставляют возможности сохранения “графов” объектов, однако сохраняемая информация не оптимизирована для выполнения запросов к хранимым данным так, поиск необходимой информации в XML-файле, содержащем несколько тысяч записей, может оказаться неприемлемо медленным. В большинстве подобных случаев в качестве хранилища информации подойдет реляционная СУБД данные сохраняются в таблицах, для дополнительного контроля целостности между ними устанавливаются отношения, поиск информации осуществляется с использованием языка запросов SQL. Аналогичную функциональность предоставляют специальные библиотеки Object/Relational Mapping (O/R Mapping). Такая библиотека перекладывает на себя всю “черную” работу по сохранению/загрузке информации из объектной модели приложения в реляционную модель базы данных. В .NET Framework 1.2 для этих целей есть специальный набор классов из пространства имен System.ObjectSpaces.*.

ObjectSpaces

Если раньше, используя ADO.NET, нужно было самостоятельно писать SQL-запросы, то теперь это требование становится необязательным ObjectSpaces берут на себя всю заботу об отображении классов приложения на различные источники данных. При этом мы можем создавать новые объекты, сохранять их, выполнять различные запросы - все необходимые действия по взаимодействию с источником данных будут выполняться внутри ObjectSpaces (при этом данные могут находиться как в традиционной БД, так и быть представленными в XML форме)

ПРЕДУПРЕЖДЕНИЕ

Текущая версия ObjectSpaces поддерживает в качестве источника данных только SQL Server 7.0 и выше.Для объектов приложения ObjectSpaces предоставляет следующие возможности:

Прозрачное отображение экземпляров .NET объектов на источник данных.

Поддержку иерархий классов для сохраняемых объектов.

Сохранение взаимосвязей между объектами (один к одному, один ко многим, многие ко многим).

Отложенную загрузку связанных объектов. Построение запросов с использованием OPath.

Архитектура ObjectSpaces

Какая функциональность требуется от O/R Mapping-библиотеки? Кроме очевидных задач загрузки/сохранения состояния объекта и выполнения операций поиска, есть и менее очевидные задачи отслеживание состояния и идентификация объекта. Для чего это нужно?

Отслеживание состояния требуется для принятия решения о необходимости сохранения объекта. Совершенно очевидно, что если ни одно из полей объекта не изменялось, то повторно сохранять ту же информацию совершенно не обязательно. Информация об оригинальных значениях полей может понадобиться и для достижения “оптимистической параллельности” (optimistic concurrency) в ситуациях, когда в БД нет колонки с версией записи. Также можно оптимизировать сохранение полей объекта для ситуаций, когда один объект отображается на несколько таблиц в базе данных, просто не обновляя не изменившиеся данные.

ПРИМЕЧАНИЕ

Optimistic concurrency (оптимистический параллелизм) это возможность двум независимым клиентам редактировать одну и ту же информацию без дополнительной блокировки каких-либо ресурсов. Все проверки относительно правомочности сделанных изменений осуществляются только в момент сохранения записи. Это можно реализовать, например, добавлением в таблицу специального поля для идентификации версии записи (например, timestamp).В каких случаях нужно уметь идентифицировать объект? В случае с O/R Mapping-библиотекой мы работаем не с “сырыми” данными, а с реальными объектами. Это значит, что одному значению первичного ключа в базе данных должен соответствовать один объект в приложении. В самом деле, разумно рассчитывать, что все возможные способы получения одного и того же объекта из базы данных каждый раз должны возвращать одну и ту же ссылку. Это означает, что O/R Mapping-библиотека должна отслеживать все загружаемые объекты, и в случае повторной попытки восстановить объект с тем же значением первичного ключа возвращать ссылку на уже загруженный.

Какие есть пути для реализации подобной функциональности? Реализация функциональности идентификации объектов пересекается с реализацией отслеживания состояния объекта и не представляет особой сложности. Поэтому сосредоточимся на том, какими способами можно обеспечить отслеживание состояния.

Есть два варианта отслеживания состояния объекта. В первом варианте инициатором сохранения состояния выступает сам объект. По второму варианту объект играет пассивную роль, а вся необходимая функциональность реализуется в библиотеке O/R Mapper. Разберем каждую из двух реализаций более подробно.

Инициатором сохранения выступает объект. В данной ситуации O/R Mapper предоставляет механизм хранения оригинальных и текущих значений, а “сохраняемый” объект выступает лишь интерфейсом для работы c этим хранилищем. Здесь можно выделить два возможных направления:

“Сохраняемый” класс описывается на некотором метаязыке. Что это за метаязык, и какие средства работы с ним используются, в общем случае не столь важно. Отличительной особенностью данной реализации является то, что весь необходимый код отслеживания состояния генерируется на этапе разработки (компиляции). В качестве примера подобного подхода можно взять реализацию Borland Enterprise Core Objects (ECO).

Все свойства, для которых необходимо предоставить возможности “сохранения” объявляются как абстрактные, сам такой класс также становится абстрактным (MustInherit в VisualBasic). На O/R Mapping-библиотеку в такой ситуации ложится ответственность за создание наследника “сохраняемого” (например, через Reflection.Emit) класса с неизбежной реализацией всех сохраняемых свойств, и предоставление фабрики класса для его создания. Найти реализацию подобной функциональности можно в ранней preview-версии ObjectSpaces и в EntityBroker (http://www.thona-consulting.com).

У каждого из этих направлений есть свои достоинства и недостатки. Плюсом первого направления является более быстрый запуск, т.к. весь необходимый код сгенерирован еще на этапе компиляции. Между тем, этот плюс может стать и минусом если по какой-то причине реализация “отслеживания” состояния изменится, придется повторить операцию генерации кода сохраняемого класса и перекомпилировать его. В случае использования второго направления будет достаточно заменить реализацию O/R Mapper.

Объект играет пассивную роль, вся реализация в O/R Mapper. В этой ситуации к “сохраняемому” классу не предъявляется никаких дополнительных требований. Основной плюс данного подхода состоит в том, что для добавления “сохраняемости” к существующему классу его не надо никак модифицировать (максимальная прозрачность в использовании O/R Mapper), а минус состоит в том, что для сохранения закрытых полей класса приходится использовать механизмы рефлексии, что может отрицательно сказаться на производительности.

В ObjectSpaces выбран второй вариант. В основе реализации ObjectSpaces (Рисунок 1) лежат три основных класса: ObjectEngine, ObjectContext и ObjectSpace.

ObjectEngine (его использование более подробно рассматривается ниже) отвечает за низкоуровневое взаимодействие с источником данных.

ObjectContext это реализация механизмов идентификации и отслеживания состояния “сохраняемых” классов.

ObjectSpace. Класс ObjectSpace на более высоком уровне объединяет функциональность, заложенную в реализациях ObjectEngine и ObjectContext. Для отображения реляционной модели данных в объектную ObjectSpace использует набор XML-схем, описываемых классом MappingSchema.

Рисунок 1 Архитектура ObjectSpaces.

Схемы данных

Для большинства приложений описать однозначное (“один к одному”) отображение объектной модели данных на реляционную модель нельзя, иногда нужно специально описывать то, как объекты должны отображаться на источник данных. В ObjectSpaces эту задачу выполняет класс MappingSchema (пространство имен System.Data.Mapping). Данный класс предназначен для описания:

RSD (Relational Schema Definition) схемы, которая описывает таблицы, поля и отношения между ними;

OSD (Object Schema Definition) схемы, описывающей объекты;

MSD (Mapping Schema Definition) схемы отображения.

ObjectSpaces дает возможность самостоятельно формировать состояние класса MappingSchema или загружать его состояние из XML-файла. Рассмотрим использование MappingSchema на основе базы данных Northwind из состава SQL Server. На первом этапе нужно описать структуру этой базы данных в RSD-схеме:

<rsd:Database Name="Northwind" Owner="sa"

"> xmlns:rsd="http://s

Похожие работы

1 2 3 4 > >>