Смотря на дизайн инструмент для Перевода Бизнес-логики от Хранимых процедур до Бизнес-Слоя C#
Не входя в дискуссию о том, должна ли бизнес-логика быть в базе данных или на прикладном уровне, так как это было покрыто в другом месте.
Моя команда переводит 100K + строки МН / кода SQL и перемещает логику от базы данных в приложение. Мы использовали VB6 с прямыми вызовами к Oracle 9i Хранимые процедуры и Специальные запросы и теперь используем C#, .net 3.5, Winforms с NHibernate к базе данных Oracle 9i.
Мы уже нашли, что замечательный инструмент помогает в преобразовании Специальных запросов, SmartCode, но это только создает код на основе Таблиц и Представлений. Мы ищем инструмент для помощи в преобразовании Хранимых процедур.
Хранимые процедуры имеют большую часть Бизнес-логики в них, что мы хотим мигрировать на прикладной уровень. Мы задаемся вопросом, существуют ли какие-либо инструменты для преобразования Хранимых процедур в код C#.
Принятие там не ни один, каково было бы лучшее место, чтобы запуститься, если мы разрабатываем инструмент источник in-house/open. Есть ли другая аналогичная система с подобными целями, которые могли использоваться в качестве стартового места?
Принятое ОБНОВЛЕНИЕ Ответа: Я выбрал ответ расползания границ проекта, потому что это, кажется, лучший метод для реализации проблемы, представленной в вопросе. Для тех, которые имеют дело с этой той же проблемой, я сердечно рекомендую ответ Adam, как он сильно защитил против использования инструмента и обеспечивает сильное объяснение. Он также обеспечил большую часть взаимодействия с этим вопросом и имел наиболее проголосовавший ответ.
Спасибо всем для Вашей справки и диалогового окна.
5 ответов
Один из способов сделать это - использовать ANTLR v3 для создания специфичного для предметной области языка. В ANTLR V3 есть граммер PL / SQL Pl / SQL для 10g, 11g для создания лексера / парсера для PL / SQL, что будет первым шагом. Генератор кода C # 3.0 доступен для серверной части для C # 3.0. Генератор кода все еще находится в стадии разработки, но находится в продвинутом состоянии.
Я не знаю, сколько работы потребовалось бы при таком подходе, но я определенно думаю, что это будет стоить меньше, чем ручной перевод.
Доступна книга под названием Окончательный справочник по ANTLR: Создание предметно-ориентированных языков . Я знаю, что предлагать книгу сейчас, когда у вас много работы, - глупо, но это даст вам представление о задействованном процессе и, возможно, достаточно, чтобы стоить конверсии.
Уже был вопрос о переполнении стека: Написание языкового переводчика , который связан с проектом ANTLR Morph, который является подпроектом для определения общего механизма перевода. В Документе и FAQ объясняется, как это работает. По сути, сценарий используется для определения механизма перевода. Он еще находится на ранних стадиях, но на него стоит обратить внимание, так как это распространенный сценарий, который еще не был рассмотрен.
В этом примере объясняется, как создать преобразования дерева, то есть переход по дереву для вывода переведенного кода, который можно найти здесь: Перевод дерева , со связанной документацией ANTLR: Согласование дерева
Поиск подходящего компилятора инженер будет ключом к успеху. Я просмотрел некоторые сайты, и на них есть несколько инженеров-компиляторов. Я думаю, что было бы дешевле нанять 1 или 2 инженеров-компиляторов на 3+ месяца для выполнения работы, чем нанять более 4 инженеров на 3+ месяца для ручного перевода. В Великобритании вы будете искать подрядчика для этого.
Надеюсь, что это поможет Боб.
Редактировать: 01/08
Я нашел другую книгу, в которой обсуждается создание языковых переводчиков, найденную здесь, под названием Шаблоны реализации языка
Я не верю, что существуют конвертеры для SQL в C #.
Что касается подхода к созданию такого инструмента, я бы сначала сказал, не надо ... ваше бизнес-требование звучит так, как будто оно заключается в том, чтобы встроить логику в C #.
В зависимости от состояния приложения вы можете делать это разными способами: по одному за раз; логические объекты одновременно (вся логика клиента и т. д.); весь боров; Agile-ish, когда вы на время оставляете sprocs в покое и вызываете их прямо из C #, а затем медленно принимаете один из предыдущих подходов - всегда оставляя себя с работающим приложением.
Действительно загруженный вопрос: -)
Я лично сначала попытался бы заставить его работать на C #, напрямую обращаясь к sprocs.Затем возьмите логические объекты, так как вы обнаружите, что они могут ссылаться на другие sprocs. Выполнение sproc за раз приведет к фрагментации вашей логики C # во время разработки и добавит дополнительные накладные расходы на создание бизнес-классов.
Сильная сторона модели предметной области C # - это четкие границы ответственности и группировка поведения по логическим объектам - поэтому, взяв за один шаг, вы не увидите более широкой картины. Использование конвертера приведет к нечитаемому, неуправляемому коду, который вам затем придется выучить - то, что вам не нужно делать, если вы его изначально создавали.
Итак, мой вывод, если он есть, состоит в том, чтобы сэкономить время в будущем и использовать это как возможность изменить свой бизнес-уровень - поскольку у вас, вероятно, есть знания и опыт производственного поведения системы из дикой природы, поэтому конверсия может учесть любые извлеченные уроки.
Обновление: оказывается, у вас есть инструменты для преобразования. Единственное, что я скажу по поводу этого подхода: полученный код не будет красивым . У вас есть преимущество в том, что ваш текущий SQL понятен команде разработчиков - они знают код. Генератор кода будет производить 100% новый код, который никто не знает . Кривая обучения ... поскольку вам потребуется проверить результат работы инструмента, чтобы убедиться, что он не изменяет вашу логику - ни один инструмент не является безошибочным.
Если вы решите использовать этот инструмент, я могу только предложить разбить преобразование на очень, очень маленькие части (предположительно, самая маленькая будет сценарием (или, возможно, даже пакетом внутри сценария)).Если у вас есть небольшой набор результатов преобразования, интегрируйте его в приложение и передайте его на проверку.
Я не смог найти ничего, что конвертирует 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 #
На основе информации, полученной от Scope-creep, Адама и Ира-Бакстера. В частности, что касается упрощения работы, четких границ ответственности и группирования поведения
. Одним из способов было бы расширить инструмент SmartCode, который уже генерирует удобные объекты для работы, и поскольку он является открытым исходным кодом:
- Расширьте инструмент для чтения в хранимых процедурах, позволяя выбирать хранимые процедуры с обратным выбором таблицы / представления (при условии, что в хранимых процедурах есть какие-либо ссылки на таблицы / представления, которые в настоящее время не отображаются).
- Используя сущности, созданные таблицами и представлениями, преобразуйте пакеты, содержащие хранимые процедуры, в иерархию классов.
- Переведите бизнес-логику с помощью лексиконов и грамматик.
Мысли?
Надеюсь, это поможет:
- Создание объявлений хранимых процедур для NHibernate в PL / SQL
- Создание оболочки хранимых процедур для NHibernate в PL / SQL
Если вы выполняете NHibernate с Oracle, вам нужно читать блог Devio.
-
- Строительные блоки для вашего кода: сущности, типы значений, типизированные списки, типизированные представления и вызовы хранимых процедур.