I don't believe there are any converters for SQL to C#.
As for approaching the creation of such a tool, I would first say, don't... your business requirement sounds like it is to get the logic into C#.
Depending on the state of the application, you can do this in many ways: one sproc at a time; logical entities at a time (all customer logic, etc); whole hog; agile-ish where you leave the sprocs alone for the time being and call straight into them from C#, and then slowly take one of the prior approaches - always leaving yourself with a functioning application.
Loaded question really :-)
I personally would first try to get it working in C# straight calling into the sprocs. Then take logical entities, as you will find they may reference other sprocs. Doing a sproc at a time will fragment your C# logic during development and add extra overhead to the creation of business classes.
The strength in a C# domain model is the clear boundaries of responsibility and grouping of behaviour into your logical entities - so taking a sproc at a time, you will not see the bigger picture. Using a converter, it will end in unreadable, unmanageable code that you then have to learn - something you don't need to do if you created it in the first place.
So my conclusion, if there is one, is to save yourself time in the future and take this as an opportunity to redesign your business layer - as you likely have knowledge and experience of the system's production behaviour from out in the wild, so the conversion can factor in any lessons learnt.
Update: it turns out you have tooling options for the conversion. The only thing I will say to that approach is this: the resulting code is not going to be pretty. You have the benefit that your current SQL is understood by the development team - they know the code. A code generator is going to produce 100% new code that no one knows. Learning curve... as you are going to need to verify the output of the tool to make sure it isn't mutating your logic - no tool is infallible.
If you decide to use the tool, I can only suggest to break the conversion down into very, very small parts (presumably the smallest is going to be a script (or perhaps even batch within a script)). When you have a small set of conversion results, integrate this into the application and pass it through a review process.
Stack Overflow 上已经有一个问题：Writing a Language Translator，链接到ANTLR Morph 项目，这是一个定义通用翻译机制的子项目。 文档和常见问题解答 解释其工作原理。本质上，脚本用于定义翻译机制。虽然还处于早期阶段，但值得一看，因为这是一种常见的情况，尚未得到解决。
One way to do it is to use ANTLR v3, to construct a domain specific language. ANTLR V3 has a PL/SQL Pl/SQL grammer for 10g,11g to construct a lexer/parser for PL/SQL, which would be the first step. A C# 3.0 code generator is available for the backend for C#3.0. The code generator is still under development, but it's in an advanced state.
I don't know how much work would ensue with this approach, but I certainly think it would cost less than doing manual translation.
There is a book available called The Definitive ANTLR Reference: Building Domain-Specific Languages . I know suggesting a book at this time, when you have a sh't load of work to do is crass, but it will give you an idea of the process involved, and perhaps enough to cost the conversion.
There has already been a question on Stack Overflow: Writing a Language Translator which links to the ANTLR Morph project, which is a subproject to define a common translation mechanism. The Doc and FAQ explain how it works. Essentially a script is used to define a translation mechanism. Its in early stages yet, but could be worth a look, as this is a common scenario which has not been addressed as yet.
This example explains how do create tree transformations, i.e. walking the tree to output translated code, found here: Tree Translations, with associated ANTLR documentation: Tree Consuruction
Finding the right compiler engineer would be key to success. I had a look at some sites, and their are a few compiler engineers available. I think it would be less expensive employing 1 or 2 compiler engineers for 3+ months, to do the work than employing than 4+ engineers for 3+ months for manual translation. In the UK you would be looking for a contractor to do it.
I couldn't find anything that converts PL/SQL directly to C#, but found a couple products that convert PL/SQL to Java (which you can then convert to C#).
Based on the input from scope-creep, Adam and Ira-Baxter. Especially, concerning doing things in a bite-sized fashion, clear boundaries of responsibility and grouping of behavior
One way would be to extend the SmartCode tool, which is already generating nice entities to work with and since it is open-source:
Extend the tool to read in the stored procedures, allowing for selection of stored procedures with reverse table/view selection (assuming there are any references in the stored procedures for tables/views not currently mapped).
Using the entities created by the tables and views, convert the packages, with containing stored procedures, to a class hierarchy.
Translate the business logic using lexicons and grammars.
发布评论
评论（5）
我不相信有任何 SQL 到 C# 的转换器。
至于如何创建这样一个工具，我首先要说的是，不要...您的业务需求听起来像是要将逻辑放入 C# 中。
根据应用程序的状态，您可以通过多种方式执行此操作：一次一个存储过程；一次逻辑实体（所有客户逻辑等）；整头猪；敏捷式，您暂时保留存储过程并直接从 C# 调用它们，然后慢慢地采用先前的方法之一 - 始终为自己留下一个正常运行的应用程序。
确实是加载的问题:-)
我个人会首先尝试让它在 C# 中直接调用存储过程。然后采用逻辑实体，因为您会发现它们可能引用其他存储过程。一次执行一个存储过程会在开发过程中分散您的 C# 逻辑，并为创建业务类增加额外的开销。
C# 域模型的优势在于清晰的责任边界和将行为分组到逻辑实体中 - 因此一次获取一个存储过程，您将看不到更大的图景。使用转换器，它将以不可读、难以管理的代码结束，然后您必须学习这些代码 - 如果您首先创建了它，则不需要这样做。
因此，我的结论（如果有的话）是为了将来节省您的时间，并以此为契机重新设计您的业务层 - 因为您可能已经从野外获得了系统生产行为的知识和经验，因此转换可以考虑任何经验教训。
更新：事实证明您有用于转换的工具选项。对于这种方法，我唯一要说的是：生成的代码不会很漂亮。您的好处是开发团队可以理解您当前的 SQL - 他们知道代码。代码生成器将生成 100% 没人知道的新代码。学习曲线...因为您需要验证工具的输出以确保它不会改变您的逻辑 - 没有工具是绝对正确的。
如果您决定使用该工具，我只能建议将转换分解为非常非常小的部分（大概最小的部分将是一个脚本（或者甚至可能是脚本内的批处理））。当您拥有一小组转换结果时，请将其集成到应用程序中并通过审核流程。
I don't believe there are any converters for SQL to C#.
As for approaching the creation of such a tool, I would first say, don't... your business requirement sounds like it is to get the logic into C#.
Depending on the state of the application, you can do this in many ways: one sproc at a time; logical entities at a time (all customer logic, etc); whole hog; agile-ish where you leave the sprocs alone for the time being and call straight into them from C#, and then slowly take one of the prior approaches - always leaving yourself with a functioning application.
Loaded question really :-)
I personally would first try to get it working in C# straight calling into the sprocs. Then take logical entities, as you will find they may reference other sprocs. Doing a sproc at a time will fragment your C# logic during development and add extra overhead to the creation of business classes.
The strength in a C# domain model is the clear boundaries of responsibility and grouping of behaviour into your logical entities - so taking a sproc at a time, you will not see the bigger picture. Using a converter, it will end in unreadable, unmanageable code that you then have to learn - something you don't need to do if you created it in the first place.
So my conclusion, if there is one, is to save yourself time in the future and take this as an opportunity to redesign your business layer - as you likely have knowledge and experience of the system's production behaviour from out in the wild, so the conversion can factor in any lessons learnt.
Update: it turns out you have tooling options for the conversion. The only thing I will say to that approach is this: the resulting code is not going to be pretty. You have the benefit that your current SQL is understood by the development team - they know the code. A code generator is going to produce 100% new code that no one knows. Learning curve... as you are going to need to verify the output of the tool to make sure it isn't mutating your logic - no tool is infallible.
If you decide to use the tool, I can only suggest to break the conversion down into very, very small parts (presumably the smallest is going to be a script (or perhaps even batch within a script)). When you have a small set of conversion results, integrate this into the application and pass it through a review process.
一种方法是使用 ANTLR v3 来构建领域特定语言。 ANTLR V3 有一个 PL/SQL Pl/SQL grammer 为 10g、11g 到为 PL/SQL 构建一个词法分析器/解析器，这是第一步。 AC# 3.0 代码生成器可用于 C#3.0 的后端。代码生成器仍在开发中，但处于高级状态。
我不知道这种方法会带来多少工作量，但我当然认为它的成本比手动翻译要低。
有一本名为权威 ANTLR 参考：构建领域特定语言的书。我知道在这个时候，当你有一大堆工作要做时，推荐一本书是很愚蠢的，但它会让你了解所涉及的过程，也许足以花费转换成本。
Stack Overflow 上已经有一个问题：Writing a Language Translator，链接到ANTLR Morph 项目，这是一个定义通用翻译机制的子项目。 文档和常见问题解答 解释其工作原理。本质上，脚本用于定义翻译机制。虽然还处于早期阶段，但值得一看，因为这是一种常见的情况，尚未得到解决。
此示例解释了如何创建树转换，即遍历树以输出翻译后的代码，可在此处找到：树翻译，以及相关的 ANTLR 文档：树构建
找到合适的编译器工程师将是成功的关键。我浏览了一些网站，他们有一些可用的编译器工程师。我认为雇用 1 或 2 名编译器工程师 3 个多月来完成这项工作比雇用 4 个以上工程师 3 个多月进行手动翻译要便宜。在英国，您需要寻找承包商来做这件事。
希望有帮助
鲍勃.
编辑：01/08
我找到了另一本书讨论创建语言翻译器，在这里找到，名为
语言实现模式
One way to do it is to use ANTLR v3, to construct a domain specific language. ANTLR V3 has a PL/SQL Pl/SQL grammer for 10g,11g to construct a lexer/parser for PL/SQL, which would be the first step. A C# 3.0 code generator is available for the backend for C#3.0. The code generator is still under development, but it's in an advanced state.
I don't know how much work would ensue with this approach, but I certainly think it would cost less than doing manual translation.
There is a book available called The Definitive ANTLR Reference: Building Domain-Specific Languages . I know suggesting a book at this time, when you have a sh't load of work to do is crass, but it will give you an idea of the process involved, and perhaps enough to cost the conversion.
There has already been a question on Stack Overflow: Writing a Language Translator which links to the ANTLR Morph project, which is a subproject to define a common translation mechanism. The Doc and FAQ explain how it works. Essentially a script is used to define a translation mechanism. Its in early stages yet, but could be worth a look, as this is a common scenario which has not been addressed as yet.
This example explains how do create tree transformations, i.e. walking the tree to output translated code, found here: Tree Translations, with associated ANTLR documentation: Tree Consuruction
Finding the right compiler engineer would be key to success. I had a look at some sites, and their are a few compiler engineers available. I think it would be less expensive employing 1 or 2 compiler engineers for 3+ months, to do the work than employing than 4+ engineers for 3+ months for manual translation. In the UK you would be looking for a contractor to do it.
Hope that helps
Bob.
Edit: 01/08
I've found another book which discusses creating language translators, found here, called
Language Implementation Patterns
我找不到任何可以将 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#代码的工具
I couldn't find anything that converts PL/SQL directly to C#, but found a couple products that convert PL/SQL to Java (which you can then convert to C#).
Convert PL/SQL to Java:
SwisSQL: http://www.swissql.com/products/oracle-to-java/oracle-to-java.html
Exodus: http://www.ciphersoftinc.com/products/plsql-to-java-conversion-tools.html
Convert Java to C#
StackOverflow answer: Tool to convert java to c# code
基于来自scope-creep、Adam 和Ira-Baxter 的输入。特别是，关于以一口大小的方式做事、明确的责任界限和行为分组，
一种方法是扩展 SmartCode 工具，该工具已经生成了可以使用的很好的实体，并且因为它是开源的：
想法？
Based on the input from scope-creep, Adam and Ira-Baxter. Especially, concerning doing things in a bite-sized fashion, clear boundaries of responsibility and grouping of behavior
One way would be to extend the SmartCode tool, which is already generating nice entities to work with and since it is open-source:
Thoughts?
我希望这有帮助：
如果您正在使用 NHibernate Oracle，您想阅读 Devio 的博客。
LLBLGen Pro功能：
I hope this helps:
If you're doing NHibernate with Oracle, you want to read Devio's blog.
LLBLGen Pro feature: