CRM でのアーリー バインディングとレイト バインディングの長所と短所を調査しています。この件についてはよくわかったのですが、いくつか不明な点があります。
早い入札が最速であると言う人もいれば、遅い入札であると言う人もいます。大きな違いはありますか？
カスタム エンティティの事前バインディングをどのように処理しますか?
カスタム フィールドを持つ既定のエンティティの事前バインディングをどのように処理しますか?
たくさんのリンクがありますが、私がマウスを置いた中で最も役に立ったのはそれらでした。他のポインタはありますか？
早い入札が一番速いという人もいれば、遅い入札という人もいます。大きな違いはありますか？
a. アーリー バウンドはレイト バウンド エンティティ クラスの単なるラッパーであり、そのすべての機能が含まれているため、レイト バウンドよりも実行時間を短縮することはできません。しかし、この違いは非常に小さく、私は What's Fastest タイプの質問で Eric Lippertとは異なります。無視できない速度の違いの 1 つは、開発の速度です。アーリー バウンドは開発がはるかに高速であり、エラーが発生しにくい IMHO です。
カスタム エンティティの事前バインディングをどのように処理しますか?
a. CrmSrvcUtil は、デフォルトのものとまったく同じように、カスタム エンティティの初期バインド クラスを生成します (クラスの生成をさらに簡単にするためにこのツールを作成しました。 更新:その後、GitHub Update 2に移動しました。現在は XrmToolBox プラグイン ストアにあります。用"Early Bound Generator")。CRM エンティティに変更が加えられるたびに、エンティティ タイプの定義を更新する必要があります (新しいプロパティまたはエンティティを使用する場合、または現在使用しているプロパティまたはエンティティを削除した場合のみ。実際には存在しないプロパティの値を設定しない限り、期限切れのアーリー バインド エンティティ クラス。これは遅延バインドの要件とまったく同じです)。
カスタム フィールドを持つ既定のエンティティの事前バインディングをどのように処理しますか?
a. 質問 2 の回答を参照してください。
アーリー バインド エンティティを操作する際のちょっとした落とし穴の 1 つは、IOrganizationService. これは では簡単ですがOrganizationServiceProxy、プラグインや特にカスタム ワークフロー アクティビティではさらにいくつかの手順が必要になる場合があります。
以下は私のコードで、かなり非アクティブなローカル開発環境に対してテストしています。気軽にテストしてみてください
using (var service = TestBase.GetOrganizationServiceProxy())
{
var earlyWatch = new Stopwatch();
var lateWatch = new Stopwatch();
for (int i = 0; i < 100; i++)
{
earlyWatch.Start();
var e = new Contact() { FirstName = "Early", LastName = "BoundTest"
e.Id = service.Create(e);
earlyWatch.Stop();
lateWatch.Start();
var l = new Entity();
l.LogicalName = "contact";
l["firstname"] = "Late";
l["lastname"] = "BoundTest";
l.Id = service.Create(l);
lateWatch.Stop();
service.Delete(e);
service.Delete(l);
}
var earlyTime = earlyWatch.ElapsedMilliseconds;
var lateTime = lateWatch.ElapsedMilliseconds;
var percent = earlyWatch.ElapsedTicks / (double)lateWatch.ElapsedTicks;
}
私の 2 つのテスト結果 (2 つのテストを実行することは、何らかの統計的結論を導き出すために統計的に有意ではないことに注意してください。テストを中断する他のアクティビティがほとんどないローカル開発環境に対して。
Number Creates | Early (MS) | Late (MS) | % diff (from ticks)
10 | 1242 | 1106 | 12.3%
100 | 8035 | 7960 | .1%
では、数値を差し込んで違いを見てみましょう。12% は多いように思えますが、12% は何ですか? 実際の差は .136 秒でした。毎分10 個作成するとしましょうContacts... .136 x 60 分/時間 x 24 時間/日 = 195.84 秒/日、または 1 日約 3 秒。どちらが速いかを判断するために、開発者に 3 時間を費やすとします。プログラムがそれほど多くの時間を節約できるようにするためには、より高速なコードが「返済」するために、24 時間年中無休の 10 連絡先/分の処理に 60 日かかり、意思決定に 3 時間かかります。
したがって、ルールは、最初に高速なものよりも読みやすく/保守しやすい方法を常に選択することです。パフォーマンスが十分に速くない場合は、他の可能性を検討してください。しかし、100 回中 98 回は、エンド ユーザーが検出できるようなパフォーマンスへの影響は実際にはありません。
時期尚早の最適化は諸悪の根源-- DonaldKnuth
ただし、これらの MSDN の記事では、レイト バインディングがより高速になることが示唆されています。
Microsoft Dynamics CRM を使用した開発のベスト プラクティス
事前バインド型を使用する
コードが記述された時点では不明なエンティティと属性をコードで処理する必要がある場合は、Entity クラスを使用します。さらに、カスタム コードが何千ものエンティティ レコードで機能する場合、Entity クラスを使用すると、事前にバインドされたエンティティ タイプよりもわずかにパフォーマンスが向上します。ただし、コンパイル時にエンティティ名と属性名を検証できないため、この柔軟性には欠点があります。コード時にエンティティが既に定義されており、パフォーマンスのわずかな低下が許容される場合は、CrmSvcUtil ツールを使用して生成できる事前バインド型を使用する必要があります。詳細については、「コードでアーリー バインド エンティティ クラスを使用する」を参照してください。
Microsoft Dynamics CRM のマネージ コードの開発スタイルを選択する
エンティティ プログラミング (アーリー バウンド vs. レイト バウンド vs. 開発者向け拡張機能)
アーリー バウンド ... ネットワーク経由での送信中にエンティティがレイト バウンド型に変換されるため、シリアライゼーション コストが増加します。
2 & 3. カスタム フィールドまたはエンティティに対して特別な操作を行う必要はありません。Svcutil は両方のクラスを生成します。
コード生成ツールによって作成されたクラスには、エンティティのすべての属性と関係が含まれます。コードでクラスを使用することにより、これらの属性にアクセスしてタイプ セーフにすることができます。組織内のすべてのエンティティに対して、属性と関係を持つクラスが作成されます。システム エンティティとカスタム エンティティの生成された型に違いはありません。
余談ですが、私はそこまでこだわる必要はありません。どちらも許容できる実装方法であり、ほとんどの状況では、パフォーマンスへの影響が心配するほど大きくなるとは思えません。個人的には遅延バインディングを好みますが、それは主に、クラスを生成する必要がないためです。
編集。
200 と 5000 のセットで CRM にアカウントを作成することで、これに関する簡単なプロファイリングを実行しました。Microsoft から提供された情報を確認すると、どちらの実行でも遅延バインディングの方が約 8.5 秒高速でした。非常に短い実行では、遅延バインディングは大幅に高速で、90% です。ただし、事前バインディングはすぐに速度を上げ、5000 レコードが作成されるまでに、遅延バインディングはわずか 2% 速くなります。
