Пожалуйста, извините за мое многословное объяснение, но я хотел быть максимально откровенным в надежде получить как можно больше полезных отзывов о моей ситуации. Вы можете перейти к вопросам внизу, если вы нетерпеливы.
Объяснение
На моей нынешней работе разработка ведется на устаревшем языке, который жестко привязан к проприетарной СУБД, поставляемой с этим языком. Язык ориентирован на CRUD и, по сути, является прославленным языком запросов / отчетов / обновлений баз данных с некоторыми функциями программирования, которые были задокументированы. Большинство программ являются процедурами сверху вниз, и повторное использование кода очень мало; Обновление записи часто требует обновления многих запутанных связанных записей одновременно, о которых вам просто нужно «знать», поскольку в собственной базе данных нет внутренних связей внешних ключей. Если необходимо обновить таблицу, мы, как правило, должны выполнить поиск исходного кода и обновить каждую процедуру, которая создает / обновляет записи для этой таблицы, и перекомпилирует. Я мог бы продолжить с другими неприятностями, но само собой разумеется, я ищу способ абстрагировать как можно большую часть этого поведения в сегменты кода многократного использования.
Язык недавно добавил некоторую поддержку объектно-ориентированной разработки, и я смог продемонстрировать преимущества многократно используемого кода моим коллегам с недавним проектом, написанным с использованием OO-конструкций. Однако мой проект был возможен только потому, что это была редкая задача, которая не требовала взаимодействия с нашей базой данных.
Я действительно изо всех сил пытался найти способ создания повторно используемого кода с использованием ОО-технологий на этом языке, но, поскольку все ориентировано на базу данных, мне действительно нужен способ создания контейнерных классов вокруг наших конструкций таблиц. помещая большую часть нашей логики обработки данных в методы класса и объединяя N связанных таблиц в один единственный класс. Это привело меня к идее фреймворков ORM, которых, конечно, не существует в языке, который я использую на работе.
Что я обнаружил , так это то, что СУБД для этого языка может запускать механизм SQL99 одновременно с механизмом проприетарного языка и включает драйверы JDBC и ODBC. Это открыло мне дверь для изучения миграционных стратегий, и я думаю, что в конечном итоге нам необходимо это сделать. Поскольку механизм SQL работает одновременно со старым механизмом, мы можем выполнять поэтапную миграцию, запуская новый код вместе со старым кодом с возможной целью переноса наших данных в «чистую» СУБД SQL после замены всего старого кода. .
Изначально я довольно много читал и предложил Java (используя JPA2 для ORM) своему менеджеру, но, думаю, я его напугал, поскольку он рассматривает Java как тяжеловесный для наших нужд. Затем я немного покопался и повторно предложил Ruby, используя интерпретатор JRuby (используя либо ActiveRecord, либо DataMapper для ORM), который был гораздо лучше воспринят, так как Rails, кажется, хорошо вписывается в перенос нашего проекта на Web внешние интерфейсы, к которым мы пытаемся перейти с нашим старым неуклюжим кодом, и, конечно, потому что возможность взаимодействия с Java в случае необходимости - это отличная возможность.
Вопросы
Почти все чтения у меня есть
делал о ORM ориентирован на
начиная со структуры класса, и
создание сопоставленной базы данных
структура как вторичный процесс.
Будет наоборот
(начиная с существующей базы данных
и отображение классов к нему) очень
странная вещь?
Предположим, вопрос № 1 == правда, как
гибки существующие рамки ORM
такие как JPA2, ActiveRecord,
DataMapper и т. Д. Для "несовершенной" таблицы
дизайн? Я уверен, что нам придется
провести рефакторинг существующих
дизайн стола, но хотелось бы знать
если я беру на себя задачу Геракла
прежде чем я трачу слишком много времени на
усилие.
Если у кого есть идея получше
язык + ORM, я хотел бы услышатьЭто. Он должен быть готов к SQL с использованием JDBC
или ODBC, чтобы вписаться в наш инкрементный
план миграции.
Если у кого-то есть опыт в подобных усилиях и он может указать какие-либо полезные ресурсы (особенно книги), я был бы очень признателен!