Linq到Salesforce“SQL”提供程序

所以,我有了这个新项目。我的公司使用SalesForce.com云存储有关日常操作的信息。我的工作是写一个新的应用程序,它将除此之外,更无缝地集成这个数据的CRUD操作和现有的内部应用程序功能。

Salesforce WSDL API的核心是一组“query()”web方法,它们将查询命令作为字符串。查询的语法是SQL-ish,但不完全是(他们称之为SOQL)。我不喜欢“神奇字符串”,所以我想在代码库中使用Linq,并将IQueryable解析为服务包装器中所需的SOQL查询。这当然是可能的(L2E,L2Sql),但我想知道是否有捷径,因为如果我说自己的滚动需要一到两天的时间,我会被“鼓励”找到另一个方法(最有可能是每个通用查询的一个方法,这是旧应用程序中使用的方法)。如果我成功地制作了一个通用的SOQL解析器,我们可以在其他几个即将推出的应用程序中使用它,我将成为一个英雄。即使我做了一个只支持特定查询结构的简单查询,它也会让我以Linq-y的方式继续当前项目,并且我可以在空闲时间扩展它。

以下是我看到的选项:

• 构建表达式树分析器。它至少需要支持Select和Where方法调用,并且需要解析lambdas或操作它们的方法体以获得所需的操作和投影。这似乎是一项相当艰巨的任务,但正如我所说,这当然是可能的。
• 在LINQ2SQL或类似的现有LINQ提供程序中包装服务,允许我提取一个足够接近的查询字符串,将其擦亮并传递给服务。外面肯定有几十个(尽管没有一个是顺便进来的,阿飞)。
• 调用Expression.ToString()(或Expression.DebugView),并操作该字符串以创建SOQL查询。它会很脆弱,很难看(在幕后),它只支持我明确寻找的东西,但它会提供一个基本的翻译,让我继续前进。

你们觉得呢?对于一个人来说,构建Linq解析器不仅仅是两天的任务吗?一个现有的LINQ提供程序的解决方案是否可行?将表达式字符串切碎并以这种方式构造查询会很糟糕吗?

感谢柯克的停飞。我进一步研究了即使是一个基本的SOQL解析器也需要做些什么,这超出了我按照任何可行的时间表编写工作应用程序代码的范围。例如,我必须从select()方法lambda或者从WSDL对象的所有已知列中构建一个select列表,这是一个我甚至没有想到的任务(我更关注Where解析)。我相信还有很多其他的“未知的未知”会把这件事变成一件大事。我找到了几个链接,这些链接展示了编写Linq提供者的基本知识,尽管它们都试图使其简单化,但现在还不太可能。现在,我将使用封装命名查询的命名方法(formattable查询字符串的一个常量类应该可以减少维护时的麻烦)来构建我的存储库。不完美,但更可行。如果Linq2SOQL提供程序启动,无论是内部的还是开源的,我们都可以重构。

• Building a Linq Provider
• Walkthrough: Creating an IQueryable LINQ Provider
• Linq: Building an IQueryable provider series - in 17 parts! <——这本书虽然篇幅长,涉及面广,但有很多真正深入的解释,很适合“初来乍到的人”。