ArtemE Jun 26 2013 at 18:01

Пишем ORM для Delphi

9 min

17K

Delphi*Programming*

From sandbox

+20

Comments 26

jonie Jun 26 2013 at 19:02

Прикольно, конечно, но не было желания переписать на что-то более новое чем дельфи7?
Про MessageBox и обработку ошибок уже дописал автор, поэтому пост отредактирован 8)

ArtemE Jun 26 2013 at 19:31

В процессе было много желаний. Хочется иметь такой инструмент на любой версии, потому как лично для меня это компонент, который делает работу интереснее. А реализация появилась только под Delphi 7 исключительно в виду того, что проект над которым я работал был написан на этой версии. Если эти наработки вызовут интерес, я с радостью попробую развить их в что-то стоящее.

Magister7 Jun 26 2013 at 20:20

А не смотрели в сторону tiOPF? Там довольно много возможностей, судя по описанию.

ArtemE Jun 26 2013 at 22:02

tiOPF очень неплохой вариант. И кроме него оценил открытый hcOPF, крайне интересный InstantObjects и разглядывал издалека закрытый TMS Aurelius.

Magister7 Jun 26 2013 at 22:52

А если сравнить их между собой в двух словах — что лучше/удобнее/проще?
Я сам пока ничем из них не пользовался, только немного в свободное время изучал документацию и примеры tiOPF — мне этот фреймворк показался мощным, но одновременно довольно сложным и многословным.
Если вас не затруднит — сравните в двух словах их. Возможно, мне стоит начать с чего-то другого? (уточню, что один из важных для меня пунктов — поддержка FreePascal).

ArtemE Jun 26 2013 at 23:05

Если вкратце, я на 100% знаю что в tiOPF есть поддержка FreePascal, а на счет остальных почти уверен что ее нет. И увы, я не работал с ними что бы дать качественное сравнение. Если у вас есть время пробовать — посмотрите тройку InstantObjects, tiOPF и DORM (у последних двух как минимум есть нормальная документация).

Magister7 Jun 26 2013 at 23:19

Жаль, что не работали. У меня, к сожалению, сейчас времени свободного нет, как и задач для которых подобный фреймворк был бы нужен.
По свободе буду разбираться, но это будет нескоро…

darked Jun 26 2013 at 23:06

Поддерживаю просьбу.

ArtemE Jun 26 2013 at 23:32

У TiOPF есть своя документация, хорошие примеры, форум, он развивается.
Поддерживает

Interbase/Firebird via IBX
Firebird via FBLib
Firebird via ZeosLib (experimental)
Oracle via DOA
MS Access & MS SQL-Server via ADO
Paradox via BDE
XML via MSDOM or FPC's DOM
CSV files
TAB files
There is also a lightning fast, custom XML persistence layer for local databases, and
a HTTP/XML layer & proxy server for building remote systems that can connect through corporate firewalls.

Этим он лучше многих прочих. Вы быстро найдете ответ по интересующему вас вопросу, используя TiOPF.
Я не знаю, есть ли поддержка > RDS 2006
Минус у всех один — слабый язык запросов, но для большинства нужд — пойдет.
Лично я бы использовал его. (это не сочтется за рекламу?)

Magister7 Jun 27 2013 at 01:34

У tiOPF немного непонятна структура веток. Есть tiOPF 2 и tiOPF 3, причем коммиты и там и там постоянно есть.
Что использовать, не совсем понятно. Третья у меня, насколько я помню, собираться не захотела. Вторую так и не попробовал…

ArtemE Jun 27 2013 at 01:37

tiOPF3 для RDS 2009, а tiOPF2 для вас. Напрасно вы не попробовали вторую ветку ;)

SOLON7 Jun 26 2013 at 21:22

мдее действительно сложный велосипед. Я тоже года назад встал на путь переплюнуть популярный DPS.
Аффтор сколько занимает реализация ORM суммарно количестве строк кода ?? Больше 2 тыс строк кода или как ??
Вам с таким подходом надо работать в Colvir или в ЦФТ…
www.cft.ru/
colvir.ru/

ArtemE Jun 26 2013 at 21:45

Увы, я не смог понять направленность вашего комментария. В статье все подробно описано. Речь идет не о полноценной ORM, которая была написана для своих собственных нужд, решающая весьма узкий круг задач. Там меньше 500 строк кода. А что определяет количество строк кода?

SOLON7 Jun 26 2013 at 21:49

затраченное время и в следствие сложность проекта. исходники Win2000 20 млн строк кода…

serbod Jul 1 2013 at 08:26

2К строк кода можно за 4 часа не особо напрягаясь написать. Главное — знать суть, а описать эту суть кодом не сложнее, чем выразить мысли буквами.

RolexStrider Jun 26 2013 at 21:43

Воистину, чем дальше, тем больше Delphi 7 мне чем-то напоминает COBOL с Fortran-ом, только на территории ex-USSR.

kuaw26 Jun 27 2013 at 04:52

В более новых версиях Делфи есть аннотации, что позволяет имена таблиц и полей не тащить в названия свойств и классов, а прописывать в аннотациях.

ivanra Jun 27 2013 at 10:44

Мне нравится MVC подход и очень хотелось разделить код логики с кодом модели.

На самом деле модель это данные и бизнес-логика. Хотя, довольно часто случается встречать такое понимание, что модель это бездумный persistence слой, а вся логика — в контроллере. В данном же случае скорее речь идет о паттерне DAO.
А конкретно по реализации: действительно RTTI это копейки по сравнению с сетевым обменом (с базой данных), так что опасаться за быстродествие действительно не стоит.
Я когда-то тоже делал что-то подобное, только там DAO слой реализовали с помощью нескольких словарных таблиц (они использовались для генерации SQL, и много для чего еще). Плюс был признак кеширования — объекты с таким признаком сохранялись некоторое время в кеше и при последующем обращении уже не извлекались из базы. Вот это действительно позволило увеличить быстродействие на порядки. Кстати, способность к кешированию есть во многих современных ORM.
По коду: в Delphi нет сборщика мусора, так что надо повнимательней. Если создал какой — то объект, то в конце следует обязательно удалить, лучше оформить это в try-finally:

someObject:=TSomeObject.Create();
try {
  ..
} finally {
  someObject.Destroy();
}

Сейчас в коде есть явные утечки

ArtemE Jun 27 2013 at 10:50

Спасибо, очень конструктивно. Устраню утечки и отпишусь в посте. А коим образом у вас происходило кеширование? Можно взглянуть одним глазком на вашу реализацию?

ivanra Jun 27 2013 at 11:27

На самом деле все это писалось более 10 лет назад, а последний раз код я видел более 5 лет назад, так что только по памяти.
Идея такая: доступ к объектам БД осуществлялся либо через произвольный SQL, либо с помощью «словарных» функций (DAO). При произвольном SQL ничего не кешировалось, а вот если это словарный доступ, и объект имел признак кеширования, то результат запроса добавлялся в кеш.
Кеш представлял собой карту

ключ записи <-> запись

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

название_объекта <-> кеш этого объекта

). Суперкарта имела ограниченный объем, если к объекту долго не обращались, его кеш удалялся из суперкарты путем замещения.
Ну и в добавок различные сервисные функции, типа
— принудительно прочитать таблицу в кеш
— очистить кеш таблицы
— очистить весь кеш
— начать и закончить кеширование принудительно (аналог сессии hibernate)
Писали по наитию, когда перешли на java, увидели много знакомого :)
Естественно, подход не универсальный, и есть риски. Но для работы со статическими данными (различные справочники, lookup-поля) — самое оно.

ArtemE Jun 27 2013 at 11:38

Ответил ниже. Веткой ошибся, глупо вышло

ArtemE Jun 27 2013 at 12:42

Исправил утечки в коде из статьи и залил изменения на BitBucket.

serbod Jul 1 2013 at 08:48

Сколько людей — столько и мнений. Для меня лично модель — это что-то из области метаданных, скорее класс, чем объект. Но при разговорах с другими называю моделями бизнес-объекты, которые могут отображаться на экране и сохраняться в БД. А вот бизнес-логика может быть как встроенной в модель, так и отдельно. Зависит от задачи, архитектуры, времени, настроения, итд… В одном моем проекте все модели — тупо строки таблиц, а логика где-то рядом с представлением. В другом — полноценные объекты со встроенной логикой, кучей методов и взаимосвязей. И мне лично больше нравится вариант с тупыми моделями, они не увеличивают сложность проекта при развитии, да и представление чаще редактируется вместе с логикой, чем с моделями.

ArtemE Jun 27 2013 at 11:36

Да, здорово. И в реализации не сложно, на сколько я могу судить.

serbod Jul 1 2013 at 08:51

Молодец. Следующий шаг — автоматическое построение структуры БД по моделям из проги.

А еще рекомендую перейти с Delphi 7 на Lazarus.

java73 Apr 18 2017 at 20:04

Пожалуй, попробую перенести в лазарус, спасибо за наводку. А вот вопрос, здесь, как я понимаю, идет полное зеркальное отображение таблиц бд в объекты, поля бд = свойствам объектов. А как-то решена проблема маппинга связей один-ко-многим и многие-ко-многим? Я у себя добавляю к объектам свойства с типом списка для заполнения уже внутри объекта списочного свойства соответствующими объектами. Но тут только хардкодинг помогает (пока). В tiOPF паттерн relation manager пытаюсь понять, но пока никак на себе не применю. Плюс еще есть одна загвоздка. Связь многие-ко-многим при маппинге в объекты может повлечь дикую рекурсию (прямой пример: юрлицо имеет участников — юрлиц, объект юрлицо имеет свойство список участников, список состоит из объектов юрлиц, ну а как иначе?), вот такие проблемы как решали, если были?