6

だから、私はこの新しいプロジェクトを持っています。私の会社では、SalesForce.com クラウドを使用して、日常業務に関する情報を保存しています。私の仕事は、とりわけ、このデータの CRUD 操作を既存の社内アプリケーション機能とよりシームレスに統合する新しいアプリケーションを作成することです。

Salesforce WSDL API の中心は、クエリ コマンドを文字列として受け取る一連の「query()」Web メソッドです。クエリの構文は SQL っぽいですが、完全ではありません (彼らはそれを SOQL と呼んでいます)。私は「魔法の文字列」が好きではないので、コードベースで Linq を使用し、サービスのラッパーで必要な SOQL クエリに IQueryable を解析したいと考えています。それは確かに可能です (L2E、L2Sql)、しかし近道があるかどうか知りたいです。別の方法 (古いアプリで使用されていた一般的なクエリごとの方法である可能性が最も高い)。汎用の SOQL パーサーの作成に成功すれば、今後のいくつかのアプリでそれを使用できるようになり、私はヒーローになります。

私が見ているオプションは次のとおりです。

  • 既存の Linq2SOQL プロバイダーをもっと探してください (私の Google-fu はここで私を失敗させています。そうでなければ、単に 1 つもありません。唯一の .NET ラッパーは、あると便利なものとして Linq について言及しているだけです)。
  • 式ツリー パーサーを構築します。少なくとも Select メソッドと Where メソッドの呼び出しをサポートする必要があり、ラムダを解析するか、メソッド本体を操作して、必要な操作とプロジェクションを取得する必要があります。これはかなり大規模な作業のように思えますが、私が言ったように、それは確かに可能です。
  • Linq2Sql または同様の既存の Linq プロバイダーでサービスをラップします。これにより、十分に近いクエリ文字列を抽出し、洗練してサービスに渡すことができます。そこには何十人もいるに違いありません（立ち寄っただけの人はいませんが、知る限り）。
  • Expression.ToString() (または Expression.DebugView) を呼び出し、その文字列を操作して SOQL クエリを作成します。それはもろく、（舞台裏で）醜く、私が明示的に探しているものだけをサポートしますが、先に進むことができる基本的な翻訳を提供します.

皆さんはどう思いますか？Linq パーサーの作成は、1 人の人間にとって 2 日以上の作業でしょうか? 既存の Linq プロバイダーが関与する行き詰まりのソリューションは、おそらくそれを行うでしょうか? 式の文字列を切り刻んで、そのようにクエリを作成するのはひどいことでしょうか?

編集：接地のためのカークに感謝します。基本的な SOQL パーサーでさえ、何をする必要があるかをさらに調べましたが、実行可能なスケジュールでアプリケーション コードを作成することは、私の範囲を超えています。たとえば、Select() メソッドのラムダから選択リストを作成するか、WSDL オブジェクトのすべての既知の列から選択リストを作成する必要があります。 . これをかなり大きな問題に変える可能性のある他の多くの「未知の未知」があると確信しています. Linq プロバイダーの作成の基本を示すいくつかのリンクを見つけました。それらはすべて単純化しようとしていますが、現時点では時間的に実現可能ではありません。今のところ、リポジトリを構築します。名前付きクエリをカプセル化する名前付きメソッドを使用します (書式設定可能なクエリ文字列の定数クラスは、メンテナンスで頭を悩ませる量を減らす必要があります)。完全ではありませんが、はるかに実現可能です。Linq2SOQL プロバイダーが社内またはオープンソースで軌道に乗った場合、リファクタリングできます。

Linq プロバイダーのリファレンスを探している他の人のために、私が見つけた役立つリンクを次に示します。

4

1 に答える 1

3

それらを 1 つずつ見ていきましょう。

既存の Linq2SOQL プロバイダーをもっと探してください (私の Google-fu はここで私を失敗させています。そうでなければ、単に 1 つもありません。唯一の .NET ラッパーは、あると便利なものとして Linq について言及しているだけです)。

ええ、すでに存在するとは思えませんが、見つけていただければ幸いです。

式ツリー パーサーを構築します。少なくとも Select メソッドと Where メソッドの呼び出しをサポートする必要があり、ラムダを解析するか、メソッド本体を操作して、必要な操作とプロジェクションを取得する必要があります。これはかなり大規模な作業のように思えますが、私が言ったように、それは確かに可能です。

長期的に真剣に考えているのであれば、これは間違いなく進むべき道です。

Linq2Sql または同様の既存の Linq プロバイダーでサービスをラップします。これにより、十分に近いクエリ文字列を抽出し、洗練してサービスに渡すことができます。そこには何十人もいるに違いありません（立ち寄っただけの人はいませんが、知る限り）。

「立ち寄る」ってどういう意味ですか？L2S から直接 SQL を簡単に取得できます。

Expression.ToString() (または Expression.DebugView) を呼び出し、その文字列を操作して SOQL クエリを作成します。それはもろく、（舞台裏で）醜く、私が明示的に探しているものだけをサポートしますが、先に進むことができる基本的な翻訳を提供します.

少なくとも、式ツリーを適切に解析するのと同じくらい難しいので、このアプローチはお勧めしません。どちらかといえば、これを使用するには、最初に解析された文字列を適切なオブジェクト モデル (つまり、開始する既存の式ツリー) に配置する必要があります。

本当に、クエリ プロバイダーを構築し、これを正しく行うことを検討する必要があります。可能かもしれませんが、原始的な意味で何かを機能させるには、2 日間は少し無理が​​あると思います。IMO、基本的な部品や部品にある程度慣れるように、自宅で調べたり、いじったりする必要があります。その場合、2 日後には使用可能なクエリをほとんど取得できない可能性があります。

正直なところ、この種のプロジェクトを完全に実装するには、実際には、数か月とは言わないまでも、数日ではなく数週間かかります。

それが大変な場合は、オプション 3 を検討してください。私は SOQL の専門家ではないので、通常の SQL クエリを SOQL クエリに変換するのにどのような作業が必要になるかわかりません。それがかなりアルゴリズム的で信頼できると思うなら、それが良い方法かもしれません。

于 2010-11-06T19:06:59.823 に答える