Повсеместная распространенность обеих моделей (РСУБД и ООП) и «несогласованный импеданс» между ними побудил многих людей попытаться перебросить мост. Этот программный мост получил название «объектно-реляционное отображение» (Object-Relational Mapper — ORM).
К этой задаче существуют разные подходы. У каждого есть свои достоинства и недостатки. Ниже мы рассмотрим два популярных ORM:
ActiveRecord
и
Og
(последняя аббревиатура обозначает «object graph» — граф объектов).
Библиотека
ActiveRecord
для Ruby названа в честь предложенного Мартином Фаулером (Martin Fowler) паттерна проектирования «Active Record» (активная запись). Смысл его в том, что таблицам базы данных сопоставляются классы, в результате чего данными становится возможно манипулировать без привлечения SQL. Точнее говоря, «она (активная запись) обертывает строку таблицы или представления, инкапсулирует доступ к базе данных и наделяет данные логикой, присущей предметной области» (см. книгу Martin Fowler «Patterns of Enterprise Application Architecture», Addison Wesley, 2003 [ISBN: 0-321-12742-0e]).
Каждая таблица описывается классом, производным от
ActiveRecord::Base
. Как и в случае с DBI, для установления соединения нужно предоставить достаточно информации для идентификации пользователя и базы данных. Вот небольшой пример, демонстрирующий весь механизм в действии:
Библиотека предлагает богатый и сложный API. Я рекомендую ознакомиться со всеми руководствами, которые вы сможете найти в сети или в книгах. Поскольку эта библиотека составляет неотъемлемую часть системы «Ruby on Rails», то мы еще вернемся к ней в главе, посвященной этой теме.
Og
отличается от
ActiveRecord
тем, что в центре внимания последней находится база данных, а первая делает упор на объекты,
Og
может сгенерировать схему базы данных, имея определения классов на языке Ruby (но не наоборот).
При работе с
Og
нужен совсем другой стиль мышления; она не так распространена, как ActiveRecord. Но мне кажется, что у этой библиотеки есть свои «изюминки», и ее следует рассматривать как мощный и удобный механизм ORM, особенно если вы проектируете базу данных исходя из структуры имеющихся объектов.
Определяя подлежащий хранению класс, мы пользуемся методом
property
, который похож на метод
attr_accessor
, только с ними ассоциирован тип (класс).
class SomeClass
property :alpha, String
property :beta, String
property :gamma, String
end
Поддерживаются также типы данных
Integer
,
Float
,
Time
,
Date
и пр. Потенциально возможно связать со свойством произвольный объект Ruby.
Соединение с базой данных устанавливается так же, как в случае
ActiveRecord
или
DBI
.
db = Og::Database.new(:destroy => false,
:name => 'mydb',
:store => :mysql,
:user => 'hal9000',
:password => 'chandra')
У каждого объекта есть метод
save
, который и вставляет соответствующую ему запись в базу данных:
obj = SomeClass.new
obj.alpha = "Poole"
obj.beta = "Whitehead"
obj.gamma = "Kaminski"
obj.save
Имеются также методы для описания связей объекта в терминах классической теории баз данных:
class Dog
has_one :house
belongs_to :owner
has_many :fleas
end
Эти, а также другие методы, например
many_to_many
и
refers_to
, помогают создавать сложные связи между объектами и таблицами.
Библиотека
Og
слишком велика, чтобы ее документировать на страницах этой книги. Дополнительную информацию вы можете найти в онлайновых источниках (например, на сайте.
10.5. Заключение
В данной главе был представлен обзор ввода/вывода в Ruby. Мы рассмотрели сам класс
IO
и его подкласс
File
, а также связанные с ними классы, в частности
Dir
и
Pathname
. Мы познакомились с некоторыми полезными приемами манипулирования объектами
IO
и файлами.
Также было уделено внимание вопросам хранения данных на более высоком уровне, точнее, на внешних носителях в виде сериализованных объектов. Наконец, мы дали краткий обзор решений, которые Ruby предлагает для интерфейса с настоящими базами данных, а кроме того, познакомились с некоторыми объектно-ориентированными подходами к взаимодействию с реляционными СУБД.
