Linq to Salesforce“SQL”提供者
所以，我有这个新项目。我的公司使用 SalesForce.com 云来存储有关日常运营的信息。我的工作是编写一个新的应用程序，除其他外，该应用程序将更无缝地将该数据的 CRUD 操作与现有的内部应用程序功能集成。
Salesforce WSDL API 的核心是一组“query()”Web 方法，这些方法将查询命令作为字符串。查询的语法类似于 SQL，但又不完全是 SQL（他们称之为 SOQL）。我不喜欢“魔术字符串”，所以我想在代码库中使用 Linq，并将 IQueryable 解析为我在服务包装器中需要的 SOQL 查询。这当然是可能的（L2E，L2Sql），但我想知道是否有捷径，因为如果我说自己需要一两天以上的时间，我会“鼓励”找到另一种方法（很可能是每个通用查询的方法，这是旧应用程序中使用的方法）。如果我成功制作了通用 SOQL 解析器，我们就可以在其他几个即将推出的应用程序中使用它，我将成为英雄。即使我制作一个仅支持某些查询结构的简单项目，它也会大有帮助，因为它允许我以 Linq-y 方式继续当前项目，并且我可以在空闲时间对其进行扩展。
以下是我所看到的选项：
- 更加努力地寻找现有的 Linq2SOQL 提供程序（我的 Google-fu 在这里让我失望，否则根本就没有提供程序；唯一的 .NET 包装器只提到 Linq 作为一个必备品）。
- 构建表达式树解析器。它至少需要支持 Select 和Where 方法调用，并且需要解析 lambda 或操作它们的方法体以获得所需的操作和投影。这似乎是一项相当艰巨的任务，但正如我所说，这当然是可能的。
- 将服务包装在 Linq2Sql 或类似的现有 Linq 提供程序中，这将允许我提取足够接近的查询字符串，对其进行完善并将其传递给服务。那里肯定有几十个（据我所知，尽管没有一个是直接进来的）。
- 调用 Expression.ToString() （或 Expression.DebugView），并操作该字符串以创建 SOQL 查询。它会很脆弱，它会很丑陋（在幕后），并且它只会支持我明确寻找的内容，但它将提供一个基本的翻译，让我继续前进。
你们觉得怎么样？对于一个人来说，构建一个 Linq 解析器不仅仅是一项两天的任务吗？涉及现有 Linq 提供商的改进解决方案可能会做到这一点吗？切碎表达式字符串并以这种方式构建我的查询会很糟糕吗？
编辑：感谢柯克的接地。我更多地研究了即使是基本的 SOQL 解析器也需要做什么，这超出了我按照任何可行的时间表编写工作应用程序代码的范围。例如，我必须从 Select() 方法 lambda 中构建一个选择列表，或者从 WSDL 对象的所有已知列中构建一个默认列表，这是一项我什至没有想到的任务（我更多地关注Where 解析） 。我确信还有许多其他“未知的未知因素”可能会使这成为一件大事。我发现了几个链接，其中显示了编写 Linq 提供程序的基础知识，尽管它们都试图使其变得简单，但目前从时间角度来看，这是不可行的。现在，我将使用封装命名查询的命名方法来构建我的存储库（格式化查询字符串的常量类应该减少维护中的麻烦）。并不完美，但更可行。如果 Linq2SOQL 提供商开始起步，无论是内部还是开源，我们都可以进行重构。
对于其他寻找 Linq 提供程序参考的人，以下是我找到的有用链接：
- 构建 Linq 提供程序
- 演练：创建 IQueryable LINQ 提供程序
- Linq：构建 IQueryable 提供程序系列 - 分 17 部分！ <-- 这一篇虽然冗长且涉及面广，但很多真正深入的解释，对“初学者”很有好处。
So, I have this new project. My company uses the SalesForce.com cloud to store information about day-to-day operations. My job is to write a new application that will, among other things, more seamlessly integrate the CRUD operations of this data with existing in-house application functionality.
The heart of the Salesforce WSDL API is a set of "query()" web methods that take the query command as a string. The syntax of the query is SQL-ish, but not quite (they call it SOQL). I'm not a fan of "magic strings", so I'd like to use Linq in the codebase, and parse the IQueryable into the SOQL query I need in the wrapper for the service. It's certainly possible (L2E, L2Sql), but I'd like to know if there's a shortcut, 'cause if I say it'll take more than a day or two to roll my own, I'll be "encouraged" to find another method (most likely a method for each general-use query, which was the method used in older apps). If I succeed in making a general-purpose SOQL parser, we can use it in several other upcoming apps, and I'll be a hero. Even if I make a simple one that only supports certain query structures, it'll go a long way by allowing me to proceed with the current project in a Linq-y way, and I can expand on it in my free time.
Here are the options as I see it:
- Look harder for an existing Linq2SOQL provider (My Google-fu is failing me here, or else there simply isn't one; the only .NET wrapper only mentions Linq as a nice-to-have).
- Build an expression tree parser. It needs to support, at least, the Select and Where method calls, and needs to either parse lambdas or manipulate their method bodies to get the operations and projections needed. This seems to be a rather massive task, but like I said, it's certainly possible.
- Wrap the service in Linq2Sql or a similar existing Linq provider that will allow me to extract a close-enough query string, polish it up and pass it to the service. There must be dozens out there (though none that just drop in, AFAIK).
- Call Expression.ToString() (or Expression.DebugView), and manipulate that string to create the SOQL query. It'll be brittle, it'll be ugly (behind the scenes), and it will support only what I'm explicitly looking for, but it will provide a rudimentary translation that will allow me to move on.
What do you guys think? Is building a Linq parser more than a two-day task for one guy? Would a bodged-up solution involving an existing Linq provider possibly do it? Would it be terrible to chop up the expression string and construct my query that way?
EDIT: Thanks to Kirk for the grounding. I took some more looks at what I'd be required to do for even a basic SOQL parser, and it's just beyond the scope of me getting working application code written on any feasible schedule. For instance, I have to build a select list from either the Select() method lambda or a default one from all known columns from my WSDL object, a task I hadn't even thought of (I was focusing more on the Where parsing). I'm sure there are many other "unknown unknowns" that could turn this into a pretty big deal. I found several links which shows the basics of writing a Linq provider, and though they all try to make it simple, it's just not going to be feasible time-wise right now. I'll structure my repository, for now, using named methods that encapsulate named queries (a constant class of formattable query strings should reduce the amount of head-scratching in maintenance). Not perfect, but far more feasible. If and when a Linq2SOQL provider gets off the ground, either in-house or open-source, we can refactor.
For others looking for Linq provider references, here are those helpful links I found:
- Building a Linq Provider
- Walkthrough: Creating an IQueryable LINQ Provider
- Linq: Building an IQueryable provider series - in 17 parts! <-- this one, though long and involved, has a lot of real in-depth explanations and is good for "first-timers".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
让我们一次一个地看它们：
是的，我怀疑已经存在，但希望你能找到一个。
如果你真的认真对待这个问题，从长远来看，这绝对是正确的选择。
你说的“进来”是什么意思？您可以轻松地直接从 L2S 获取 SQL。
我强烈建议您不要采用这种方法，因为至少它会像正确解析表达式树一样困难。如果有的话，为了使用它，您必须首先将解析的字符串放入适当的对象模型中 - 即您开始使用的现有表达式树。
实际上，您应该考虑构建一个查询提供程序并正确执行此操作。我认为两天的时间对于让一些东西在原始意义上发挥作用来说有点漫长，尽管这可能是可能的。 IMO，你应该在家里研究一下它并尝试一下，这样你就可以熟悉基本的部件和部件。那么两天后您可能几乎无法获得一些可用的查询。
但老实说，完全实施此类项目实际上需要几周甚至几个月的时间，而不是几天。
如果工作量太大，您可以考虑选项 3。我不是 SOQL 方面的专家，因此不知道将普通 SQL 查询转换为 SOQL 查询会涉及哪些工作。如果您认为它相当算法化且可靠，那么这可能是正确的选择。
Let's take them one at a time:
Yeah, I doubt one exists already, but hopefully you can find one.
This is absolutely the way to go if you really are serious about this in the long-run.
What do you mean by "drop in"? You can easily get the SQL straight from L2S.
I would strongly discourage you from this approach, as, at minimum, it will be at least as difficult as parsing the expression trees properly. If anything, in order to use this, you'd have to first put the parsed strings into a proper object model -- i.e. the existing expression trees you're starting with.
Really, you should think about building a query provider and doing this right. I think two days is a bit of a stretch though to get something working in even a primitive sense, though it might be possible. IMO, you should research it some at home and toy around with it so you have some familiarity with the basic pieces and parts. Then you might barely be able to get some usable queries going after two days.
Honestly though, fully implementing this kind of project is really in the realm of several weeks, if not months -- not days.
If that's too much work, you might consider option 3. I'm no expert on SOQL, so no idea what kind of work would be involved transforming ordinary SQL queries into SOQL queries. If you think it's rather algorithmic and reliable, that might be the way to go.