2010-01-26 1 views
1

У нас есть приложение Java среднего размера, которое нуждается в некотором рефакторинге.Какая лучшая стратегия базы данных для JRuby on Rails + устаревший код 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 плагинов, и нужно будет управлять объектами «вручную» на стороне Руби
  • Мы могли бы использовать ActiveRecord для всего и определить какое-то избыточное отображение на стороне Java. Что было бы лучшей стратегией?
  • Мы будем использовать технологию Java ORM (Hibernate, Cayenne?), А затем сопоставить модель в ActiveRecord. Как эта идея сравнивается с предыдущей?
  • Можем ли мы сделать магию с помощью Jruby 1.4 стать_java !?

Как вы думаете?

+0

+1, черт возьми, хороший вопрос: я не удивлюсь, увидев в ближайшем будущем гораздо больше такого рода деятельности. – Roboprog

ответ

1

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

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

+0

Я уже пробовал Grails, чтобы решить мою проблему, и он потерпел неудачу, чтобы сделать то, что мне было нужно (у меня был плохой пользовательский опыт, пытаясь получить фиктивную демонстрацию, запущенную с помощью плагина Wicket). Если я собираюсь использовать что-то «рельсы», я бы предпочел использовать «настоящие рельсы». Мне не нужен юрби на рельсах <-> унаследованная интеграция Java будет совершенной. Мне просто нужно, чтобы это было «достаточно хорошо». – rodrigob

0

FYI: в книге O'Reilly «Enterprise Rails» есть некоторые полезные советы о создании собственных плагинов Rails, чтобы вы могли находить/поддерживать/повторно использовать любые трюки, которые вы придумали. Дикая догадка: сделайте плагин O/R, который вы можете использовать, чтобы сидеть поверх старого java-кода?

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

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

1

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

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

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

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

1

Ответ на этот вопрос непросто, не зная много деталей.

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

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

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

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