Программирование на языке Ruby - Хэл Фултон

Пусть имеется база данных под управлением Oracle и используется драйвер (он же адаптер), поставляемый вместе с библиотекой OCI8. Методу connect следует передать достаточно информации для успешного соединения с базой данных. Все более или менее интуитивно очевидно.

require "dbi"

db = DBI.connect("dbi:OCI8:mydb", "user", "password")

query = "select * from people"

stmt = db.prepare(query)

stmt.execute

while row = stmt.fetch do

 puts row.join(",")

end

stmt.finish

db.disconnect

Здесь метод prepare — это некий вариант компиляции или синтаксического анализа запроса, который позже исполняется. Метод fetch извлекает одну строку из результирующего набора и возвращает nil, если строк не осталось (поэтому мы и воспользовались циклом while). Метод finish можно считать вариантом закрытия или освобождения ресурсов.

Полную информацию обо всех возможностях DBI можно найти в любом справочном руководстве. Список имеющихся драйверов приведен на сайте RubyForge и в архиве приложений Ruby.

10.4.7. Объектно-реляционные отображения (ORM)

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

Повсеместная распространенность обеих моделей (РСУБД и ООП) и «несогласованный импеданс» между ними побудил многих людей попытаться перебросить мост. Этот программный мост получил название «объектно-реляционное отображение» (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, для установления соединения нужно предоставить достаточно информации для идентификации пользователя и базы данных. Вот небольшой пример, демонстрирующий весь механизм в действии:

require 'active_record'

ActiveRecord::Base.establish_connection(:adapter => "oci8",

 :username => "username",

 :password => "password",

 :database => "mydb",

 :host => "myhost")

class SomeTable < ActiveRecord::Base

 set_table_name "test_table"

 set_primary_key "some_id"

end

SomeTable.find(:all).each do |rec|

 # Обработать запись...

end

item = SomeTable.new

item.id = 1001

item.some_column = "test"

item.save

Библиотека предлагает богатый и сложный 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 слишком велика, чтобы ее документировать на страницах этой книги. Дополнительную информацию вы можете найти в онлайновых источниках (например, на сайте http://oxyliquit.de).

10.5. Заключение

В данной главе был представлен обзор ввода/вывода в Ruby. Мы рассмотрели сам класс IO и его подкласс File, а также связанные с ними классы, в частности Dir и Pathname. Мы познакомились с некоторыми полезными приемами манипулирования объектами IO и файлами.

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

Ниже мы еще вернемся к вводу/выводу в контексте сокетов и сетевого программирования. Но предварительно рассмотрим некоторые другие темы.

Глава 11. ООП и динамические механизмы в Ruby

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

Это необычная глава. В большинстве других глав рассматривается какой-то конкретный аспект, например строки или файлы, но в этой все иначе. Если расположить «пространство задачи» по одной оси системы координат, то данная глава окажется на другой оси, поскольку содержит по кусочку из всех других областей. Связано это с тем, что объектно-ориентированное программирование и динамичность сами по себе являются не задачами, а парадигмами, которые могут быть применены к решению любой задачи, будь то системное администрирование, низкоуровневое сетевое программирование или разработка приложений для Web.

Вот почему значительная часть материала данной главы должна быть уже знакома любому программисту, знающему Ruby. На самом деле все остальное в этой книге не имеет смысла без понимания изложенных здесь основ. Например, любой программист на Ruby знает, как создать подкласс. Возникает вопрос: что включить, а без чего можно обойтись? Знает ли любой программист о методе extend? А о методе instance_eval? То, что одному представляется очевидным, может оказаться откровением для другого.

Мы решили отдать предпочтение полноте. В главу включены некоторые экзотические вещи, которые можно делать с помощью динамического ООП в Ruby, но не забыты и рутинные задачи — на случай, если кто-то не знаком с ними. Мы спустились до самого простого уровня, поскольку многие по-разному представляют себе, где кончается «средний» уровень. И попытались дать кое-какую дополнительную информацию даже при изложении самых базовых вопросов, чтобы оправдать включение их в эту главу. С другой стороны, тем, которые раскрываются в других частях книги, мы здесь не касались.

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