Нужно разработать инструмент для перевода бизнес-логики из хранимых процедур в бизнес-уровень C # - PullRequest
6 голосов
/ 21 июля 2010

Не вдаваясь в дискуссию о том, должна ли бизнес-логика находиться в базе данных или на прикладном уровне, поскольку она была рассмотрена в другом месте .

Моя команда переводит 100K + строк кода PL / SQL и переносит логику из базы данных в приложение. Мы использовали VB6 с прямыми вызовами хранимых процедур Oracle 9i и специальных запросов и теперь используем C #, .net 3.5, Winforms с NHibernate для базы данных Oracle 9i.

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

Хранимые процедуры содержат большую часть бизнес-логики, которую мы хотим перенести на уровень приложений. Нам интересно, есть ли какие-либо инструменты для преобразования хранимых процедур в код C #.

Предполагая, что их нет, с чего бы лучше начать, если мы разработаем этот инструмент самостоятельно или с открытым исходным кодом. Есть ли другая похожая система с похожими целями, которую можно использовать в качестве отправной точки?

Принятый ответ ОБНОВЛЕНИЕ: Я выбрал ответ scope-creep, потому что он, кажется, лучший метод для реализации проблемы, представленной в вопросе. Для тех, кто занимается этой же проблемой, я искренне рекомендую ответ Адама, поскольку он решительно выступает против использования инструмента и дает веские основания. Он также обеспечил наибольшее взаимодействие с этим вопросом и получил наиболее одобренный ответ.

Спасибо всем за помощь и диалог.

Ответы [ 5 ]

12 голосов
/ 21 июля 2010

Я не верю, что есть конвертеры для SQL в C #.

Что касается подхода к созданию такого инструмента, я бы сначала сказал, что не ... ваше требование бизнеса звучит так, как будто вы хотите получить логику в C #.

В зависимости от состояния приложения, вы можете сделать это разными способами: по одному за раз; логические объекты одновременно (вся логика клиента и т. д.); целая свинья; agile-ish, где вы оставляете спрокеров в покое на время и вызываете их прямо из C #, а затем медленно выбираете один из предыдущих подходов - всегда оставляя себя с работающим приложением.

Действительно загруженный вопрос: -)

Лично я сначала попытался бы заставить его работать в C # прямо, вызывая sprocs. Затем возьмите логические объекты, поскольку вы обнаружите, что они могут ссылаться на других звезд. Одновременное выполнение sproc фрагментирует вашу логику C # во время разработки и добавляет дополнительные издержки при создании бизнес-классов.

Сильной стороной модели домена C # являются четкие границы ответственности и группировки поведения в ваших логических сущностях - поэтому, взяв спрок за раз, вы не увидите более широкой картины. Используя конвертер, он закончится нечитаемым, неуправляемым кодом, который вам затем придется изучить - то, что вам не нужно делать, если вы его создали в первую очередь.

Итак, мой вывод, если таковой имеется, - это сэкономить время в будущем и использовать это как возможность изменить дизайн своего бизнес-уровня - поскольку у вас, вероятно, есть знания и опыт поведения системы в этой области, таким образом, преобразование может учитывать любые извлеченные уроки.

Обновление: оказывается, у вас есть опции инструментов для конвертации. Единственное, что я скажу этому подходу, это: полученный код не будет красивым . Вы получаете преимущество в том, что ваш текущий SQL понятен командой разработчиков - они знают код. Генератор кода будет производить 100% новый код, который никто не знает . Кривая обучения ... так как вам нужно проверить вывод инструмента, чтобы убедиться, что он не изменяет вашу логику - ни один инструмент не является безошибочным.

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

2 голосов
/ 30 июля 2010

Один из способов сделать это - использовать ANTLR v3 для создания языка, специфичного для домена.ANTLR V3 имеет PL / SQL Pl / SQL грамматик для 10g, 11g для создания лексера / синтаксического анализатора для PL / SQL, что будет первым шагом.Генератор кода AC # 3.0 доступен для бэкэнда для C # 3.0.Генератор кода все еще находится в стадии разработки, но находится в продвинутом состоянии.

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

Существует книга под названием The DefinitiveСсылка ANTLR: Создание доменных языков .Я знаю, что предлагать книгу в это время, когда у вас не так много работы, - это глупо, но она даст вам представление о процессе, и, возможно, достаточно, чтобы стоить конверсии.

Уже был вопрос о переполнении стека: Написание языкового переводчика , который связан с проектом ANTLR Morph, который является подпроектом для определения общего механизма перевода. Doc и FAQ объясняют, как это работает.По сути, сценарий используется для определения механизма перевода.Он еще на ранних стадиях, но стоит посмотреть, так как это общий сценарий, который еще не был рассмотрен.

В этом примере объясняется, как создавать преобразования дерева, т.е. обходить дерево для вывода переведенного кода, найденного здесь: Перевод дерева , с соответствующей документацией ANTLR: Созвездие дерева

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

Надеюсь, что это поможет Бобу.

Редактировать: 01/08

Я нашел еще одну книгу, в которой обсуждается создание языковых переводчиков, которая называется здесь Шаблоны языковой реализации.

0 голосов
/ 30 июля 2010

Основано на материалах, полученных от scope-creep, Adam и Ira-Baxter. В частности, что касается дел размером с укус, четких границ ответственности и группирования поведения

Одним из способов было бы расширить инструмент SmartCode, который уже генерирует приятные сущности для работы, и поскольку он с открытым исходным кодом:

  1. Расширение инструмента для чтения в хранимых процедурах, что позволяет выбирать хранимые процедуры с помощью обратного выбора таблиц / представлений (при условии, что в хранимых процедурах есть ссылки на таблицы / представления, которые в настоящее время не отображаются).
  2. Используя сущности, созданные таблицами и представлениями, преобразуйте пакеты с хранимыми процедурами в иерархию классов.
  3. Переведите бизнес-логику, используя лексиконы и грамматики.

Мысли

0 голосов
/ 30 июля 2010

Я не смог найти ничего, что конвертирует PL / SQL напрямую в C #, но нашел пару продуктов, конвертирующих PL / SQL в Java (которые затем можно конвертировать в C #).

Преобразование PL / SQL в Java:

SwisSQL: http://www.swissql.com/products/oracle-to-java/oracle-to-java.html
Исход: http://www.ciphersoftinc.com/products/plsql-to-java-conversion-tools.html

Преобразование Java в C #

StackOverflow ответ: Инструмент для преобразования Java в код C #

0 голосов
/ 27 июля 2010

Надеюсь, это поможет:

Если вы работаете с NHibernate с Oracle, вы хотите прочитать блог Devio.

  • LLBLGen Pro функция:

    • Строительные блоки для вашего кода: сущности, типы значений, типизированные списки, типизированные представления и хранимая процедуразвонки.
...