logo标签列表

设计一个工具，将存储过程中的业务逻辑翻译为C#业务层。

c#oracle9i
7
不谈论业务逻辑应该在数据库还是在应用程序层的问题，因为这已经在其他地方讨论过了。
我的团队正在翻译10万+行PL/SQL代码，并将逻辑从数据库移至应用程序。我们之前使用VB6直接调用Oracle 9i存储过程和临时查询，现在则使用C#、.net 3.5、Winforms和NHibernate连接Oracle 9i数据库。
我们已经找到一个非常好的工具来帮助转换临时查询，SmartCode，但它只能基于表格和视图创建代码。我们正在寻找一个工具来帮助转换存储过程。
存储过程中有大部分我们想要迁移到应用程序层的业务逻辑。我们想知道是否有任何工具可以将存储过程转换成C#代码。
假设没有这样的工具，如果我们在内部或开源开发工具，最好从哪里开始？是否有类似目标的其他系统可供作为起点？ 已接受答案的更新: 我选择了scope-creep的答案，因为它似乎是实现所提问题的最佳方法。对于那些处理相同问题的人，我强烈推荐Adam的回答，因为他坚决反对使用工具并提供了有力的论据。他也对这个问题进行了最多的互动，并得到了最高投票。
感谢大家的帮助和讨论。
你的存储过程中有多少代码？如果全部手动转换，你认为需要多长时间？ - Ira Baxter
数千行代码。经过初步分析，大部分代码相似，只是针对特定的表格而言。我估计大约60-70%的“相似”代码涉及到空值/空字符串问题和软删除过滤。 - Lucas B
我估计手动转换代码需要很多个月的时间，这就是为什么我正在考虑使用或创建工具来完成这项任务。 - Lucas B
1
如果代码只有几千行，你很可能无法通过创建工具来节省比直接转换更少的精力。如果你的代码有10万行，使用自动化工具将是一个重大的胜利。在这两者之间...这是一场赌博，特别是如果你没有建立这种工具的经验。 - Ira Baxter
如果您有兴趣寻找一款可以解析PLSQL并可作为C#代码生成器基础的工具，请查看我的个人简介。仍然适用上述注意事项。 - Ira Baxter
显示剩余2条评论
5个回答
13

我不相信有任何将SQL转换为C#的转换器。

至于创建这种工具的方法，我首先会说，不要...你的业务需求听起来就像是要将逻辑转换为C#。

根据应用程序的状态，您可以通过许多方式实现：逐个sproc进行; 逐个逻辑实体进行（所有客户逻辑等）; 全部进行; 类似敏捷开发的方式，在此期间保留sprocs，并直接从C#调用它们，然后慢慢采用前面的方法之一 - 总是确保应用程序功能正常。

实际上是一个复杂的问题 :-)

我个人首先会尝试在C#中直接调用sprocs使其工作。 然后按逻辑实体拆分，因为您会发现它们可能引用其他sprocs。 逐个处理sproc会在开发过程中使C#逻辑碎片化，并增加创建业务类的额外开销。

C#领域模型的优势在于清晰的责任边界和行为分组 - 因此，逐个处理sproc时，您无法看到更大的画面。 使用转换器将导致代码难以阅读和管理，您还需要学习它 - 如果您最初创建它，则无需这样做。

因此，我的结论是，如果有的话，请在未来节省时间，并将其视为重新设计业务层的机会 - 因为您可能已经了解系统在生产中的行为，因此转换可以考虑任何已学习的教训。

更新：事实证明，您有转换的工具选项。唯一要说的是： 生成的代码不会很好看。 您拥有当前SQL被开发团队理解的好处-他们知道这个代码。 代码生成器将生成100% 新代码，没有人知道。 学习曲线...因为您需要验证工具的输出，以确保它不会改变您的逻辑 - 没有工具是完美的。

如果您决定使用这个工具，我只能建议将转换分解成非常非常小的部分（最小的可能是一个脚本，或者甚至是脚本中的批处理）。当您有一组小的转换结果时，请将其集成到应用程序中，并通过审查流程。
完全同意这一点...将WHERE子句拉入C#代码并创建适当的对象和架构需要太多变量。 - shookdiesel
我已经进行了进一步的分析，发现这有超过100K行的PL/SQL代码。你还同意逐个进行转换吗？我认为这需要数月的转换工作，并且容易出现错误。 - Lucas B
2
@Lucas 使用转换工具同样容易出现错误。我认为对于这么大的代码库，您需要评估迁移代码是否在财务上可行。我建议采用折中方案-让C#与您现有的SQL进行通信和使用，然后在执行项目迭代时，确保一些转换工作得到优先处理。没有简单的答案，这将是一个艰苦的过程...听起来大部分逻辑都在SQL中，因此将其转换为C#可能类似于重新编写整个应用程序，因此测试开销将非常大。 - Adam Houldsworth
@Lucas，阅读你的问题后评论中提到了Ira可以帮助你使用一种工具。如果你成功地解决了这个问题，请回来分享这个好消息-我很想看看如何将SQL转换为C＃。 - Adam Houldsworth
3
一种方法是使用ANTLR v3构建领域特定语言。ANTLR V3有一个PL/SQL grammer适用于10g、11g，用于构建PL/SQL的词法分析器/解析器，这将是第一步。针对C# 3.0的代码生成器可用于后端。代码生成器仍在开发中，但已处于先进状态。

我不知道采用此方法会带来多少工作量，但我肯定认为它的成本比手动翻译要低。

有一本书可供参考，名为The Definitive ANTLR Reference: Building Domain-Specific Languages。我知道在您有大量工作要做的时候建议一本书很粗鲁，但它会给您一个涉及的过程，并且也许足以估算转换的成本。

在Stack Overflow上已经有一个问题： 编写语言翻译器，其中链接到ANTLR Morph项目，这是一个定义通用翻译机制的子项目。文档和常见问题解答解释了它的工作原理。基本上，使用脚本来定义翻译机制。虽然它还处于早期阶段，但可能值得一看，因为这是一个尚未解决的常见情况。

这个例子解释了如何创建树形转换，即遍历树形结构以输出翻译代码，可在此处找到：树形转换，附带有关联的ANTLR文档：树构造。
找到合适的编译工程师是成功的关键。我查看了一些网站，发现有几个可用的编译工程师。我认为雇佣1或2名编译工程师进行3个月以上的工作比雇佣4名以上的工程师手动翻译3个月更少花费。在英国，您需要寻找承包商来完成此项工作。
希望对您有所帮助 鲍勃。
编辑：01/08
我找到了另一本讨论创建语言翻译器的书，可在此处找到，名为语言实现模式。
@scope-creep，有没有一些可以参考的示例项目？如果有的话，你能指给我吗？ - Lucas B
即使有良好的基础设施，构建一个好的翻译器也需要相当长的时间。实质上，你需要为每个基本的源语言习惯用法编写翻译规则，并针对那些特别感兴趣的源语言习惯用法，让所有这些元素协同工作。我的团队有做这方面的经验，对于 100K SLOC，您可能会看到大多数 PLSQL 语言元素。我猜一个真正优秀的工程师可能需要一年的时间才能完成这项工作。3名工程师在4个月内无法成功。我相信自动化翻译；但规模必须合适。 - Ira Baxter
0
1
间接的，但从技术上讲是正确的答案——不过我真的很不想看到生成的 C# 代码... - Adam Houldsworth
@Mien，这确实越来越接近了，但我同意Adam的看法，如果已经有许多层次的转换，原始逻辑会有多少保留并且可维护性会有多高呢...我将运行一些测试并回报结果。 - Lucas B
0

基于来自scope-creep、Adam和Ira-Baxter的输入，特别是关于以逐步方式完成任务、明确责任边界和行为分组的问题。

一种方法是扩展SmartCode工具，该工具已经生成了易于使用的实体，并且由于它是开源的：

  1. 扩展工具以读取存储过程，允许选择具有反向表/视图选择的存储过程（假设存储过程中存在对当前未映射的表/视图的引用）。
  2. 使用由表和视图创建的实体，将包含存储过程的包转换为类层次结构。
  3. 使用词汇表和语法翻译业务逻辑。

你有什么想法？

我不能过于具体地评论，但开源项目通常有着奇怪的代码库。你将不得不自己开发工具并测试它——基本上拥有它的总成本将会很高。此外，不能保证它可以变成你所需要的样子。我建议先取小部分应用逻辑来制作这个SmartCode工具的概念验证，然后再做决定。 - Adam Houldsworth
但是如果您可以让它做您需要的事情，那么这种方法就没有问题 - 但请戴上项目管理的帽子，问一下这将花费多少时间，相对于重新编写。后者您可以立即开始，并且不会失去您已经掌握的SQL专业知识。一个新工具是完全不同的项目。 - Adam Houldsworth
-1
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接