所以,我有了这个新项目。我的公司使用 SalesForce.com 云来存储有关日常运营的信息。我的工作是编写一个新的应用程序,除其他外,它将这些数据的 CRUD 操作与现有的内部应用程序功能更无缝地集成在一起。
Salesforce WSDL API 的核心是一组将查询命令作为字符串的“query()”Web 方法。查询的语法是 SQL 风格,但不完全是(他们称之为 SOQL)。我不喜欢“魔术字符串”,所以我想在代码库中使用 Linq,并将 IQueryable 解析为我在服务包装器中需要的 SOQL 查询。这当然是可能的(L2E,L2Sql),但我想知道是否有捷径,因为如果我说自己推出需要一两天以上的时间,我会“鼓励”找到另一种方法(很可能是每个通用查询的方法,这是旧应用程序中使用的方法)。如果我成功地制作了一个通用的 SOQL 解析器,我们可以在其他几个即将推出的应用程序中使用它,我将成为英雄。
以下是我看到的选项:
- 更加努力地寻找现有的 Linq2SOQL 提供程序(我的 Google-fu 在这里让我失望了,否则根本就没有;唯一的 .NET 包装器只提到 Linq 是一个不错的选择)。
- 构建表达式树解析器。它至少需要支持 Select 和 Where 方法调用,并且需要解析 lambda 或操纵它们的方法体以获得所需的操作和投影。这似乎是一项相当艰巨的任务,但就像我说的,这当然是可能的。
- 将服务包装在 Linq2Sql 或类似的现有 Linq 提供程序中,这将允许我提取足够接近的查询字符串,对其进行优化并将其传递给服务。那里肯定有几十个(尽管没有一个只是进来,AFAIK)。
- 调用 Expression.ToString()(或 Expression.DebugView),并操作该字符串以创建 SOQL 查询。它会很脆弱,会很丑陋(在幕后),它只会支持我明确寻找的东西,但它会提供一个基本的翻译,让我继续前进。
你们有什么感想?对于一个人来说,构建一个 Linq 解析器不仅仅是两天的任务吗?一个涉及现有 Linq 提供商的复杂解决方案可能会做到吗?切碎表达式字符串并以这种方式构造我的查询会很糟糕吗?
编辑:感谢柯克的接地。我对即使是一个基本的 SOQL 解析器也需要做更多的研究,这超出了我按照任何可行的时间表编写工作应用程序代码的范围。例如,我必须从 Select() 方法 lambda 或从我的 WSDL 对象的所有已知列中构建一个默认列表,这是我什至没有想到的任务(我更关注 Where 解析) . 我敢肯定还有许多其他“未知的未知数”可以把这变成一件大事。我发现了几个链接,这些链接显示了编写 Linq 提供程序的基础知识,尽管它们都试图使其变得简单,但现在在时间上是不可行的。现在,我将构建我的存储库,使用封装命名查询的命名方法(可格式化查询字符串的常量类应减少维护中的麻烦)。不完美,但更可行。如果 Linq2SOQL 提供程序启动,无论是内部还是开源,我们都可以重构。
对于其他寻找 Linq 提供程序参考的人,这里是我发现的那些有用的链接:
- 构建 Linq 提供程序
- 演练:创建 IQueryable LINQ 提供程序
- Linq:构建 IQueryable 提供程序系列 - 分为 17 个部分!<--这一篇,虽然冗长且涉及,但有很多真正深入的解释,适合“初学者”。