Linq zu Salesforce "SQL" Anbieter

Question

Also, ich habe dieses neue Projekt. Meine Firma verwendet die SalesForce.com-Cloud zum Speichern von Informationen zum Tagesgeschäft. Meine Aufgabe ist es, eine neue Anwendung zu schreiben, die unter anderem die CRUD-Operationen dieser Daten nahtlos in die vorhandene hauseigene Anwendungsfunktionalität integriert.

Das Herz der WSDL-API von Salesforce ist eine Gruppe von "query()" - Webmethoden, die den Abfragebefehl als Zeichenfolge verwenden. Die Syntax der Abfrage ist SQL-ish, aber nicht ganz (sie nennen es SOQL). Ich bin kein Fan von "magischen Zeichenfolgen", also möchte ich Linq in der Codebasis verwenden und das IQueryable in die SOQL-Abfrage parsen, die ich im Wrapper für den Dienst brauche. Es ist sicherlich möglich (L2E, L2Sql), aber ich würde gerne wissen, ob es eine Abkürzung gibt, denn wenn ich sage, dass es mehr als ein oder zwei Tage dauern wird, bis ich meine eigenen rollen kann, werde ich "ermutigt" zu finden eine andere Methode (wahrscheinlich eine Methode für jede allgemeine Abfrage, die in älteren Apps verwendet wurde). Wenn es mir gelingt, einen universellen SOQL-Parser zu erstellen, können wir ihn in mehreren anderen kommenden Apps verwenden und ich werde ein Held sein. Selbst wenn ich ein einfaches mache, das nur bestimmte Abfragestrukturen unterstützt, wird es einen langen Weg zurücklegen, indem ich das aktuelle Projekt auf eine Linq-y-Weise fortsetzen kann, und ich kann es in meiner Freizeit erweitern.

Hier die Optionen sind wie ich es sehe:

• Blick härter für einen vorhandenen Linq2SOQL Provider (Mein Google-Fu ist mir hier versagt, oder aber es ist einfach nicht ein, der einzige .NET-Wrapper erwähnt nur Linq als nice-to-have).
• Erstellen Sie einen Ausdruck Baum Parser. Es muss mindestens die Methodenaufrufe Select und Where unterstützen und muss entweder lambdas analysieren oder ihre Methodenkörper manipulieren, um die erforderlichen Operationen und Projektionen zu erhalten. Dies scheint eine ziemlich große Aufgabe zu sein, aber wie ich schon sagte, es ist sicherlich möglich.
• Wickeln Sie den Dienst in Linq2Sql oder einen ähnlichen vorhandenen Linq-Anbieter, der es mir ermöglichen wird, eine Zeichenfolge für ausreichend nahe Abfrage zu extrahieren, es aufzupolieren und es an den Dienst zu übergeben. Es muss dutzende da draußen geben (aber keine, die reinkommen, AFAIK).
• Rufen Sie Expression.ToString() (oder Expression.DebugView) auf, und bearbeiten Sie diese Zeichenfolge, um die SOQL-Abfrage zu erstellen. Es wird brüchig, es wird hässlich sein (hinter den Kulissen), und es wird nur das unterstützen, was ich explizit suche, aber es wird eine rudimentäre Übersetzung liefern, die es mir erlauben wird, weiterzugehen.

Was denkst du? Ist das Erstellen eines Linq-Parsers mehr als eine zweitägige Aufgabe für einen Typ? Könnte eine zusammengeschlossene Lösung, die einen bestehenden Linq-Anbieter betrifft, dies möglicherweise tun? Wäre es schrecklich, den Ausdrucksstring zu zerhacken und meine Anfrage so zu konstruieren?

EDIT: Danke an Kirk für die Erdung. Ich habe mir noch mehr angeschaut, was ich für einen einfachen SOQL-Parser tun müsste, und es geht einfach über den Rahmen hinaus, dass ich keinen funktionierenden Applikationscode bekomme, der nach irgendeinem realisierbaren Zeitplan geschrieben wurde. Zum Beispiel muss ich eine Auswahlliste entweder aus der Select() - Methode Lambda oder einer Standardliste aus allen bekannten Spalten meines WSDL-Objekts erstellen, eine Aufgabe, an die ich nicht gedacht hatte (ich konzentrierte mich mehr auf die Where-Analyse) . Ich bin mir sicher, dass es viele andere "unbekannte Unbekannte" gibt, die das zu einer ziemlich großen Sache machen könnten. Ich habe mehrere Links gefunden, die die Grundlagen des Schreibens eines Linq-Anbieters zeigen, und obwohl sie alle versuchen, es einfach zu machen, wird es momentan einfach nicht machbar sein. Ich werde jetzt mein Repository strukturieren, indem ich benannte Methoden benutze, die benannte Abfragen kapseln (eine konstante Klasse von formatfähigen Query-Strings sollte das Kopfkratzen in der Wartung reduzieren). Nicht perfekt, aber viel praktikabler. Wenn und wann ein Linq2SOQL-Anbieter entweder intern oder als Open-Source-Anbieter auf den Markt kommt, können wir ihn umgestalten.

Für andere suchen Linq-Anbieter Referenzen, hier sind die hilfreichen Links gefunden:

• Building a Linq Provider
• Walkthrough: Creating an IQueryable LINQ Provider
• Linq: Building an IQueryable provider series - in 17 parts! < - das ist eine, wenn auch lange und beteiligt sind, hat eine Menge echte gründliche Erklärungen und ist gut für "Erstbesucher".

Answer 1

sie sie ein zu einer Zeit nehmen:

Blick härter für einen vorhandenen Linq2SOQL Provider (Mein Google-Fu mich hier versagt, oder aber es ist einfach nicht ein, die einzige .NET Wrapper erwähnt nur Linq als nice-to-have).

Ja, ich bezweifle, dass einer existiert, aber hoffentlich können Sie einen finden.

Erstellen Sie einen Ausdruck Baum Parser. Es muss mindestens die Methodenaufrufe Select und Where unterstützen und muss entweder lambdas analysieren oder ihre Methodenkörper manipulieren, um die erforderlichen Operationen und Projektionen zu erhalten. Dies scheint eine ziemlich große Aufgabe zu sein, aber wie ich schon sagte, es ist sicherlich möglich.

Dies ist absolut der Weg zu gehen, wenn Sie auf lange Sicht wirklich ernst damit sind.

Wickeln Sie den Dienst in Linq2Sql oder einen ähnlichen vorhandenen Linq-Anbieter, der es mir ermöglichen wird, eine nah genug Abfrage-Zeichenfolge zu extrahieren, es aufzupolieren und es an den Dienst zu übergeben. Es muss dutzende da draußen geben (aber keine, die reinkommen, AFAIK).

Was meinst du mit "Drop in"? Sie können das SQL einfach direkt aus L2S beziehen.

Rufen Sie Expression.ToString() (oder Expression.DebugView) auf, und bearbeiten Sie diese Zeichenfolge, um die SOQL-Abfrage zu erstellen. Es wird brüchig, es wird hässlich sein (hinter den Kulissen), und es wird nur das unterstützen, was ich explizit suche, aber es wird eine rudimentäre Übersetzung liefern, die es mir erlauben wird, weiterzugehen.

Ich würde Sie von diesem Ansatz stark entmutigen, wie bei Minimum, es mindestens so schwierig, wie Parsen der Ausdrucksbäume richtig sein wird. Um dies zu verwenden, müssten Sie die analysierten Zeichenfolgen zunächst in ein geeignetes Objektmodell einfügen, also in die vorhandenen Ausdrucksbäume, mit denen Sie beginnen.

---

Wirklich, sollten Sie darüber nachdenken, einen Abfrage-Provider bauen und dieses Recht zu tun. Ich denke, dass zwei Tage ein bisschen eine Strecke sind, etwas sogar in einem primitiven Sinn zu arbeiten, obwohl es möglich sein könnte. IMO, du solltest es zu Hause erforschen und damit herumspielen, damit du etwas Vertrautheit mit den grundlegenden Teilen und Teilen hast. Dann könnten Sie kaum brauchbare Abfragen nach zwei Tagen bekommen.

Ehrlich gesagt, ist die vollständige Umsetzung dieser Art von Projekt wirklich im Bereich von mehreren Wochen, wenn nicht Monaten - nicht Tagen.

Wenn das zu viel Arbeit ist, können Sie Option 3 in Betracht ziehen. Ich bin kein Experte für SOQL, also keine Ahnung, welche Art von Arbeit wäre die Umwandlung von normalen SQL-Abfragen in SOQL-Abfragen. Wenn Sie denken, dass es eher algorithmisch und zuverlässig ist, könnte das der richtige Weg sein.