Озадачился вопросом есть ли нужная мне функциональность у существующих ORM фреймворков, или закатывать рукава реализовывая это все самому на JDBC.
Сразу оговорюсь, в БД не силен, поэтому могу путаться.
Итак, дано:
Есть базовая сущность Base, которая описывает какой-то базовый набор свойств, включая primary key.
В системе может быть n-ое множество наследников сущности Base, а у них в свою очередь k-oe множество наследников и так до бесконечности.
Понятно, что все наследники будут храниться в своих собственных таблицах, а базовые атрибуты брать из супер таблицы Base и может быть промежуточных супертаблиц.
Наследники Base должны создаваться в runtime, ну и естественно хранится в БД.
Что же хочется:
Хочется для всех наследников Base, использовать один POJO к примеру BasePersistence, который будет знать что именно за сущность в нем загружена, сам POJO описывает только свои атрибуты, а все значения остальных атрибутов например возвращает по какому-то методу getAttrValue(String attrName).
27.07.11 13:28: Перенесено модератором из 'Java' — Blazkowicz
Здравствуйте, Kelan, Вы писали:
K>Хочется для всех наследников Base, использовать один POJO к примеру BasePersistence, который будет знать что именно за сущность в нем загружена, сам POJO описывает только свои атрибуты, а все значения остальных атрибутов например возвращает по какому-то методу getAttrValue(String attrName).
Хочется странного. Вместо того, чтобы сделать нормальную иерархию классов, ты собираешься сделать один универсальный класс. И перед использованием специфичных для конкретного наследника Base свойств вызывать метод getType.
Зачем?
Здравствуйте, Kelan, Вы писали:
K>Итак, дано: K>Есть базовая сущность Base, которая описывает какой-то базовый набор свойств, включая primary key. K>В системе может быть n-ое множество наследников сущности Base, а у них в свою очередь k-oe множество наследников и так до бесконечности. K>Понятно, что все наследники будут храниться в своих собственных таблицах, а базовые атрибуты брать из супер таблицы Base и может быть промежуточных супертаблиц. K>Наследники Base должны создаваться в runtime, ну и естественно хранится в БД.
Этот вопрос в том или ином виде всплывает постоянно как здесь, так и в Архитектуре. Найти сложно, так как ключевых терминов нет, каждый выдумывает по-своему.
Правильный ответ таков — вы потом заманаетесь расставлять if-ы везде, где можно было бы применить полиморфизм.
Вы замучаетесь с отловом ошибок с опечатками в именах атрибутах, кто возился с динамически типизироваными языками, тот знает.
Ну, и кодить тоже будет весело, autocomplete вам никакая IDE не предложит.
Здравствуйте, Donz, Вы писали:
D>Хочется странного. Вместо того, чтобы сделать нормальную иерархию классов, ты собираешься сделать один универсальный класс. И перед использованием специфичных для конкретного наследника Base свойств вызывать метод getType. D>Зачем?
Странный вопрос зачем! Мы много за свою жизнь делаем глупостей и не только их, а что-то потом становится необходимым.
getType в самом классе вообще не будет использоваться, он только будет нужен для интерфейса, сервиса, валидаторов и т.п, который как-то должен будет идентифицировать сущность, чтобы использовать для нее набор каких-то правил.
Если кратко, необходим конструктор сущностей, обладающих одинаковыми свойствами, но которые могут добавлять также и свои свойства.
От идеи генерации байткода на лету, и сохранения его в classpath для последующих запусков сразу отказался, потому что как-то это печально (плюс обычно подразумевает перезагрузку (jvm, orm фреймворк не важно) результат один и тот же, блокировка работы для всех остальных участников процесса)
Здравствуйте, Blazkowicz, Вы писали:
B>Этот вопрос в том или ином виде всплывает постоянно как здесь, так и в Архитектуре. Найти сложно, так как ключевых терминов нет, каждый выдумывает по-своему. B>Правильный ответ таков — вы потом заманаетесь расставлять if-ы везде, где можно было бы применить полиморфизм. B>Вы замучаетесь с отловом ошибок с опечатками в именах атрибутах, кто возился с динамически типизироваными языками, тот знает. B>Ну, и кодить тоже будет весело, autocomplete вам никакая IDE не предложит.
А ещё подумайте как станут выглядеть запросы к БД с джоином по нескольким сущностям.
И как быстро будет работать единственный индекс на все аттрибуты всех записей?
Здравствуйте, Kelan, Вы писали:
K>Странный вопрос зачем! Мы много за свою жизнь делаем глупостей и не только их, а что-то потом становится необходимым.
Попробуйте остановить свою изобретательность и ответить на один вопрос — что именно в вашем решении должно стать проще в сравнении с классическим подходом.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Blazkowicz, Вы писали:
B>>Этот вопрос в том или ином виде всплывает постоянно как здесь, так и в Архитектуре. Найти сложно, так как ключевых терминов нет, каждый выдумывает по-своему. B>>Правильный ответ таков — вы потом заманаетесь расставлять if-ы везде, где можно было бы применить полиморфизм. B>>Вы замучаетесь с отловом ошибок с опечатками в именах атрибутах, кто возился с динамически типизироваными языками, тот знает. B>>Ну, и кодить тоже будет весело, autocomplete вам никакая IDE не предложит. B>А ещё подумайте как станут выглядеть запросы к БД с джоином по нескольким сущностям. B>И как быстро будет работать единственный индекс на все аттрибуты всех записей?
If-ы и прочую дребедень в коде вообще не планирую использовать, для этого много можно чего взять готового, для написания правил к примеру.
Опечатки в именах атрибутов тоже решаемы: это можно делать например валидируя имена перед сохранением настроек, или же на этапе компиляции — если она вообще будет подразумеваться.
Autocomplete, ну кхм, мне он уже давно не помощник :D кроме как набор текста.
Индекс и прочее, это уже вопрос оптимизации БД, который сейчас я не хотел бы рассматривать.
Здравствуйте, Kelan, Вы писали:
K>Странный вопрос зачем! Мы много за свою жизнь делаем глупостей и не только их, а что-то потом становится необходимым.
Прежде чем сделать что-то неочевидное, необходимо аргументировать это действие.
K>getType в самом классе вообще не будет использоваться, он только будет нужен для интерфейса, сервиса, валидаторов и т.п, который как-то должен будет идентифицировать сущность, чтобы использовать для нее набор каких-то правил.
Не совсем понял. Но все-таки, какие аргументы заставляют отказаться от классического подхода?
K>Если кратко, необходим конструктор сущностей, обладающих одинаковыми свойствами, но которые могут добавлять также и свои свойства. K>От идеи генерации байткода на лету, и сохранения его в classpath для последующих запусков сразу отказался, потому что как-то это печально (плюс обычно подразумевает перезагрузку (jvm, orm фреймворк не важно) результат один и тот же, блокировка работы для всех остальных участников процесса)
Кажется догадываюсь. Ты хочешь генерировать классы на основе БД, а в БД они могут регулярно появляться, и при этом система должна работать без пересборки клиентских приложений?
Как предполагается работать с новыми сущностями? Ведь даже если сгенерировать соответствующий класс на лету, то создать специфичные правила валидации и бизнес-логики уже не получится.
Можно конкретный пример?
Когда-то давно делал нечто подобное. Но в БД хранились не просто данные, а целиком формы с правилами отображения и переходами по тем или иным действиям. Форма парсилась, создавались объекты нужных классов (классы были уже не динамическими), туда подгружались данные и бизнес-правила.
Но у тебя, похоже, несколько иная цель.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Kelan, Вы писали:
K>>Странный вопрос зачем! Мы много за свою жизнь делаем глупостей и не только их, а что-то потом становится необходимым.
B>Попробуйте остановить свою изобретательность и ответить на один вопрос — что именно в вашем решении должно стать проще в сравнении с классическим подходом.
Меня не устраивает в классическом подходе, этап под названием разработка, хочется добиться того, чтобы было не:
Анализ, Архитектура, Настройка, Разработка, Настройка
а стало:
Анализ, Настройка.
Да будет наложено очень много ограничений, тот кто будет заниматься анализом и настройкой будет ограничен инструментами которые выдает разработчик.
Здравствуйте, Kelan, Вы писали:
K>If-ы и прочую дребедень в коде вообще не планирую использовать, для этого много можно чего взять готового, для написания правил к примеру.
Over-abstracted это серьезная проблема многих фреймверков. Вы много видели живых приложений, где всё описано абстрактными "правилами", а не конкретным Java кодом?
K>Опечатки в именах атрибутов тоже решаемы: это можно делать например валидируя имена перед сохранением настроек, или же на этапе компиляции — если она вообще будет подразумеваться.
Ну, так может сразу нафиг Java? Возьмите тот же Ruby или любой другой продвинутый скриптовый язык с ORM и пр.
Здравствуйте, Donz, Вы писали:
D>Кажется догадываюсь. Ты хочешь генерировать классы на основе БД, а в БД они могут регулярно появляться, и при этом система должна работать без пересборки клиентских приложений? D>Как предполагается работать с новыми сущностями? Ведь даже если сгенерировать соответствующий класс на лету, то создать специфичные правила валидации и бизнес-логики уже не получится. D>Можно конкретный пример?
D>Когда-то давно делал нечто подобное. Но в БД хранились не просто данные, а целиком формы с правилами отображения и переходами по тем или иным действиям. Форма парсилась, создавались объекты нужных классов (классы были уже не динамическими), туда подгружались данные и бизнес-правила. D>Но у тебя, похоже, несколько иная цель.
Конкретный пример:
Пользователь с правами на создание сущности, создает новую эту самую сущность. Настраивает свойства (выбирает для них тип значений, указывает констрейнты). Публикует эту сущность в систему.
В системе есть универсальная форма для отображения этих сущностей, которая на основе описания сущности и правил генерирует набор для редактирования или чтения базовых свойств и своих собственных.
Здравствуйте, Kelan, Вы писали:
K>Конкретный пример: K>Пользователь с правами на создание сущности, создает новую эту самую сущность. Настраивает свойства (выбирает для них тип значений, указывает констрейнты). Публикует эту сущность в систему. K>В системе есть универсальная форма для отображения этих сущностей, которая на основе описания сущности и правил генерирует набор для редактирования или чтения базовых свойств и своих собственных.
Здравствуйте, Kelan, Вы писали:
K>Анализ, Архитектура, Настройка, Разработка, Настройка K>а стало: K>Анализ, Настройка. K>Да будет наложено очень много ограничений, тот кто будет заниматься анализом и настройкой будет ограничен инструментами которые выдает разработчик.
Вы, вероятно, не видели таких проектов ещё. А я уже повидал не один.
Первый такой лет 8 назад мы даже писали. Но там по вине заказчика дальше прототипа ничего не продвинулось.
А сейчас уже второй проект переписываем из "Анализ, Настройка" в "Анализ, Архитектура, Разработка".
(Тут нужно признать, что оба проекта в определенный момент своей жизни даже были отчасти успешными, но они абсолютно не масштабируются и на определенном этапе сановятся экономичски не выгодными)
Первый был написан на платформе Magic. Тоже вроде всё просто — нарисовал форму, забиндил на таблицу, написал правило. Чем это закончилось.
— Нормализацию в базе сделать невозможно, соответсвенно масса не валидных данных
— Писать бизнес правила это программит мышью. Можно свернуть мозг. Цикл зачастую можно реализовать только вызовом под-задачи со счетчиком.
— Читать правила сложнее ЯП, они сильно абстрагированы.
— Оптимизации делать не возможно в принципе. А качество ORM оставляет желать лучшего.
— То что не может реализовать платформа, нужно оформлять в виде DLL или EXE на нормальном ЯП. А по причине того что платформа переабстрагирована, то многой конкретики в ней нет и такого кода тоже не мало.
Второй проект был написан точно так же, то на какой-то либе для Delphi. Результат — такой же. Как только компания вышла на мировой уровень, эта система стала жрать слишком много ресурсов на саппорт и работу операторов.
Вывод — один. Реальной экономической выгоды такие решения не имеют. Затраты на их разработку сравнимы с затратами на реализации классическим способом в Java. А масштабируются такие системы никак.
Здравствуйте, Kelan, Вы писали:
K>В системе есть универсальная форма для отображения этих сущностей, которая на основе описания сущности и правил генерирует набор для редактирования или чтения базовых свойств и своих собственных.
В том или ином виде такое реализовано во фреймверках вроде Seam, SmartGWT.
Только поймите что "универсальное" оно работает до тех пор пока от него кроме CRUD ничего не нужно. А кроме примеров, которые я описал выше, был у меня ещё один. Самописный "универсальный" фреймверк для Flash. Так вот каждая 10я новая фича в системе требовала трудоёмкой модификации самого фреймверка.
Если вдруг, не дай бог, вас таки угораздит подобное писать, обратите внимание на то чтобы вы всегда в любом месте могли дописать старого доброго Java кода, который умеет делать то что нужно.
Здравствуйте, Blazkowicz, Вы писали:
B>Первый был написан на платформе Magic. Тоже вроде всё просто — нарисовал форму, забиндил на таблицу, написал правило. Чем это закончилось. B>- Нормализацию в базе сделать невозможно, соответсвенно масса не валидных данных B>- Писать бизнес правила это программит мышью. Можно свернуть мозг. Цикл зачастую можно реализовать только вызовом под-задачи со счетчиком. B>- Читать правила сложнее ЯП, они сильно абстрагированы. B>- Оптимизации делать не возможно в принципе. А качество ORM оставляет желать лучшего. B>- То что не может реализовать платформа, нужно оформлять в виде DLL или EXE на нормальном ЯП. А по причине того что платформа переабстрагирована, то многой конкретики в ней нет и такого кода тоже не мало.
B>Второй проект был написан точно так же, то на какой-то либе для Delphi. Результат — такой же. Как только компания вышла на мировой уровень, эта система стала жрать слишком много ресурсов на саппорт и работу операторов.
— Смотря кто базу делал, если сам, то можно и оптимизировать.
— Смотря какие бизнес-правила, и о каких объемах идет речь. В моем случае — этот набор конечен.
— Опять же, смотря чья платформа, если своя то флаг в руки, стараться писать уже оптимизированной, насколько позволяет мозг объять масштабы будущих боевых действий.
B>Вывод — один. Реальной экономической выгоды такие решения не имеют. Затраты на их разработку сравнимы с затратами на реализации классическим способом в Java. А масштабируются такие системы никак.
Выгоды нет? Уже достаточно кажется существует помоечных мега и не очень проектов, которые давно вышли на окупаемость. Масштабирование системы — должно изначально закладываться, если оно подразумевается, а масштабировать растровую графику тоже не благодарное занятие
Вообще мы отклонились от темы, меня интересовал ORM, который мог бы удовлетворить мои потребности.
Здравствуйте, Kelan, Вы писали:
K>Вообще мы отклонились от темы, меня интересовал ORM, который мог бы удовлетворить мои потребности.
Вероятно вы не совсем ORM хотите. Потому что у вас объектов, как таковых, не предвидится. Сответсвтенно JDBC+HashMap и вперед.
Здравствуйте, stenkil, Вы писали:
S>CRM ? Посмотрите в сторону EVA DB
Применение да хоть где угодно, хоть тот же CMS, это не принципиально.
EVA DB — киньте ссылкой, что вы имеете в виду, очень много противоречивых результатов гугель выдает.
Здравствуйте, Blazkowicz, Вы писали:
B>В том или ином виде такое реализовано во фреймверках вроде Seam, SmartGWT. B>Только поймите что "универсальное" оно работает до тех пор пока от него кроме CRUD ничего не нужно. А кроме примеров, которые я описал выше, был у меня ещё один. Самописный "универсальный" фреймверк для Flash. Так вот каждая 10я новая фича в системе требовала трудоёмкой модификации самого фреймверка. B>Если вдруг, не дай бог, вас таки угораздит подобное писать, обратите внимание на то чтобы вы всегда в любом месте могли дописать старого доброго Java кода, который умеет делать то что нужно.
Seam, SmartGWT — это же UI фреймворки, с возможностью работы с разными ORM?
Здравствуйте, Blazkowicz, Вы писали:
B>Вероятно вы не совсем ORM хотите. Потому что у вас объектов, как таковых, не предвидится. Сответсвтенно JDBC+HashMap и вперед.
Вот есть мечта просто не привязываться к синтаксису конкретных БД, а использовать ORM.
Я скорее скажу hello C
