Luc*_*s B 6 c# nhibernate oracle9i
没有讨论业务逻辑应该在数据库中还是在应用程序层,因为它已经被其他地方所覆盖.
我的团队正在翻译100K +行的PL/SQL代码,并将逻辑从数据库移到应用程序中.我们使用VB6直接调用Oracle 9i存储过程和Ad-hoc查询,现在使用C#,.net 3.5,Winforms和NHibernate到Oracle 9i数据库.
我们已经找到了一个很好的工具来帮助转换Ad-hoc查询SmartCode,但它只创建基于表和视图的代码.我们正在寻找一种工具来协助转换存储过程.
存储过程中包含我们要迁移到应用程序层的大部分业务逻辑.我们想知道是否有任何工具可以将存储过程转换为C#代码.
假设没有,如果我们开发内部/开源工具,最好的起点是什么.是否有其他类似的系统具有类似的目标,可以用作起点？
接受的答案更新: 我选择了范围蠕变的答案,因为它似乎是实现问题中提出的问题的最佳方法.对于那些处理同一问题的人,我衷心地推荐Adam的回应,因为他强烈主张反对使用工具并提供强有力的理由.他还提供了与这个问题最多的互动,并且得到了最多的投票反应.
感谢大家的帮助和对话.
Ada*_*rth 12
我不相信SQL到C#有任何转换器.
至于接近创建这样一个工具,我首先要说的是,不要......你的业务需求听起来像将逻辑引入C#.
根据应用程序的状态,您可以通过多种方式执行此操作:一次一个; 一次逻辑实体(所有客户逻辑等); 整猪; agile-ish你暂时离开sprocs并从C#直接调用它们,然后慢慢采取一种先前的方法 - 总是给自己留下一个正常运行的应用程序.
真的加载问题:-)
我个人会首先尝试使用C#直接调用sprocs.然后采用逻辑实体,因为您会发现它们可能引用其他的sprocs.一次执行一个sproc会在开发期间分割您的C#逻辑,并为创建业务类增加额外的开销.
C#域模型的优势在于责任的明确界限以及将行为分组到逻辑实体中 - 因此,一次采用sproc,您将看不到更大的图景.使用转换器,它将以您无法学习的无法读取的代码结束 - 如果您首先创建它,则无需执行此操作.
所以我的结论,如果有的话,就是为了节省自己的未来时间,并以此为契机重新设计您的业务层 - 因为您可能从野外获得系统生产行为的知识和经验,因此转换可以考虑任何经验教训.
更新:事实证明,您有转换的工具选项.对于这种方法,我唯一要说的是:结果代码不会很漂亮.您的好处是开发团队可以理解您当前的SQL - 他们知道代码.代码生成器将生成100%无人知晓的新代码.学习曲线......因为您需要验证工具的输出以确保它不会改变您的逻辑 - 没有工具是绝对可靠的.
如果您决定使用该工具,我只能建议将转换分解为非常非常小的部分(可能最小的将是一个脚本(或者甚至可能是脚本中的批处理)).如果您有一小组转换结果,请将其集成到应用程序中并将其传递给审核流程.
一种方法是使用 ANTLR v3 来构建领域特定语言。ANTLR V3 有一个用于 10g、11g 的 PL/SQL Pl/SQL语法器，为 PL/SQL 构建词法分析器/解析器，这将是第一步。AC# 3.0 代码生成器可用于 C#3.0 的后端。代码生成器仍在开发中，但处于高级状态。
我不知道这种方法会带来多少工作量，但我当然认为它会比手动翻译花费更少。
有一本名为The Definitive ANTLR Reference: Building Domain-Specific Languages 的书。我知道在这个时候，当你有一大堆工作要做时，推荐一本书是很愚蠢的，但它会让你了解所涉及的过程，也许足以花费转换成本。
Stack Overflow 上已经有一个问题：编写语言翻译器，该问题链接到 ANTLR Morph 项目，该项目是定义通用翻译机制的子项目。文档和常见问题解答解释了它的工作原理。本质上，脚本用于定义翻译机制。虽然还处于早期阶段，但值得一看，因为这是一种常见的情况，尚未得到解决。
此示例解释了如何创建树转换，即遍历树以输出翻译后的代码，可在此处找到：Tree Translations，以及相关的 ANTLR 文档：Tree Consuruction
找到合适的编译器工程师将是成功的关键。我浏览了一些网站，他们有一些可用的编译器工程师。我认为雇用 1 或 2 名编译器工程师 3 个多月来完成这项工作比雇用 4 个以上工程师 3 个多月进行手动翻译要便宜。在英国，您需要寻找承包商来做这件事。
希望对鲍勃有帮助。
编辑：01/08
我找到了另一本讨论创建语言翻译器的书，可以在这里找到，名为 《语言实现模式》