Какая стратегия базы данных лучше всего подходит для унаследованного Java-кода на JRuby on Rails +?

Question

У нас есть Java-приложение среднего размера, требующее рефакторинга.

Мы рассматриваем возможность перехода на JRuby on Rails. Главным образом из-за производительности, которую предлагает Ruby on Rails, и из-за множества существующих плагинов, которые будут переопределять веб-логику.

Однако большая часть приложения должна оставаться на Java, мы не хотим переписывать всю бизнес-логику (особенно потому, что она использует многие технологии Java, такие как RMI).

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

Из JRuby мы можем вызвать любой устаревший код Java. Отлично!

Однако многие плагины Ruby on Rails предполагают использование ActiveRecord для управления базой данных. Доступ к данным ActiveRecord из Java кажется нетривиальным.

Какова наилучшая стратегия управления базой данных между JRuby on Rails и унаследованным кодом Java?

• Мы могли бы использовать db4o для всего, но потеряли бы преимущества некоторых плагинов Ruby on Rails, и нам пришлось бы управлять объектами "вручную" на стороне Ruby
• Мы могли бы использовать ActiveRecord для всего и определить какое-то избыточное отображение на стороне Java. Какая стратегия будет лучшей?
• Мы бы использовали технологию Java ORM (Hibernate, Cayenne?), А затем отобразили модель в ActiveRecord. Как эта идея соотносится с предыдущей?
• Можем ли мы сделать немного магии, используя Jruby 1.4 становиться _java!?

Что вы думаете?

Answer 1

Это сложный вопрос, не зная много деталей.

Во-первых, можно полностью создавать приложения Rails без использования ActiveRecord (AR). Я сделал несколько - обычно я использую контроллер для запуска сценариев, чтения / записи файлов и т. Д., И я считаю, что этот подход действителен. Однако, поскольку у вас определенно есть данные в базе данных, с которыми нужно иметь дело, помните о необходимости придерживаться подхода MVC, независимо от того, является ли ваш M AR или нет.

Если ваша БД хорошо спроектирована, у вас может быть гибридный подход. Например, возможно, ваша устаревшая Java генерирует отчетные данные, используя любой ORM, и записывает их в БД, таблицы из которой затем можно легко обернуть в модели ActiveRecord для отправки отчета через ваше приложение Rails. Все зависит от того, какие функции выполняет ваш Java-код, а не от того, какие функции выполняет ваш Rails-код (и снова, если ваш дизайн БД поддается моделированию AR).

Если вашему приложению rails и java-коду необходимо передавать экземпляры модели напрямую (т.е. в отличие от прохождения через базу данных), гибридный подход может не работать.

Я предлагаю подход "попробуй и посмотри". Попробуйте несколько вещей и посмотрите, как быстро вы столкнетесь с неприятностями. В таких случаях я чувствую, что попытка спроектировать все это в уме сначала не так продуктивно.

Answer 2

Похоже, что вы планируете провести небольшой рефакторинг на стороне Java в дополнение к написанию нового кода на Ruby. В таком случае я бы порекомендовал:

1) выбрать Java ORM: Hibernate или db4o и использовать его в дальнейшем во всех ваших рефакторингах Java. Как бы я ни хотел сказать, используйте ActiveRecord для всего, суть здесь в том, что убедить JRuby в работе с Java ORM будет гораздо проще, чем заставить ваш код Java работать с объектами ActiveRecord. .

2) По крайней мере, есть примеры прототипов интерфейсов Ruby для Hibernate и db4o. Найдите тот, который поможет вам начать работу, а затем добавьте его по мере необходимости, чтобы предоставить необходимые возможности ORM.

3) Не беспокойтесь о плагинах Rails, которые ожидают ActiveRecord. Не все делают, и еще меньше будет в будущем, так как Rails 3 (слияние Rails и Merb) отсоединяет ActiveRecord. И даже если есть плагин, который вам абсолютно необходим, для которого требуется ActiveRecord, ну и что? Это просто код Ruby. Загрузите его, посмотрите, что он ожидает, и скомпонуйте класс фасадов для вашего ORM, чтобы предоставить методы, которые хочет плагин. (Здесь мы видим красоту Ruby - объект не должен <> утку, если он прогуливается и крякает как один). В качестве альтернативы, вы можете обезьяна исправить плагин, чтобы удалить зависимость ActiveRecord, или просто реализовать функциональность, которую предоставляет плагин самостоятельно. Ваша ситуация, скорее всего, будет определять, какой из этих подходов имеет смысл.

Answer 3

JRuby - отличный язык, но он действительно работает на виртуальной машине Java. Можно интегрировать устаревший код Java, но он плохо вписывается в основной язык.

Если вас интересует новый динамический язык с надежной веб-структурой, я бы посоветовал посмотреть Groovy и http://grails.org/. Groovy построен на JVM. Вы унаследованные классы могут быть первоклассным гражданином в приложении. Я думаю, что было бы намного проще перейти на что-то новое, потому что вы можете повторно использовать то, что у вас есть, переписывая нужные вам части.

Answer 4

К вашему сведению: в книге О'Рейли "Enterprise Rails" есть несколько полезных советов о том, как создавать свои собственные плагины Rails, чтобы вы могли находить / поддерживать / повторно использовать любые уловки, которые вам придутся. Дикая догадка: сделать на O / R плагин, который вы можете по желанию использовать поверх старого Java-кода?

Альтернативно, создайте некоторую магию в базе данных, чтобы позволить старой java магическим образом читать результаты "нового и улучшенного!" рубиновая обработка?!? Я предполагаю, что БД с представлениями, триггерами и доступом для использования таких.

Удачи, у меня нет хорошего ответа, но мне очень интересно, как это сработает для вас.