Listクライアント オブジェクト モデルのみを使用して、SharePoint サイトの変更をリッスンするかなり効率的な方法を探しています。この考えがどれほど古いものかは理解していますが、インストール時にライブラリを SharePoint サーバーにプッシュする必要がないようにしています。すべてがローカル マシンにドロップ アンド ゴーされるはずです。
タイマーをループして、クエリが成功した最後の日付からクエリを続けるクラスについて考えましたClientContextが、それは恐ろしく非効率的です。
これがクライアントオブジェクト モデルであることはわかっていますが、クライアントのみからの変更についてサーバーから通知を受け取る方法はありますか?
残念ながら、これはクライアント オブジェクト モデルを使用することでは不可能です。あまりにも頻繁にポーリングする必要があり、パフォーマンスの低下によってユーザー エクスペリエンスが大幅に低下する場合は、サーバー側でリストの変更をキャッチする必要があります。SPItemEventReceiverをリストに登録する機能を備えたソリューションを展開します。
サーバー側のコードを SP ファームにプッシュすることに抵抗があることは理解しています。それがなくても、ディスカッションや説明を顧客の管理者に保存できます。ただし、一部のタスクは、サーバー上で実行する場合にのみ、より効率的または実現可能です。このような機能については、サンドボックス ソリューションを検討できます。それらは、ファーム管理者によってではなく、サイト コレクション管理者によってサイト コレクションに SP に展開されます。フレンドリーな Web UI によって。これにより、必要な特権が少なくなり、準拠する会社のポリシーが緩和され、顧客により受け入れられるようになります。ファーム全体に影響を与えることなく、サイト コレクションのみでソリューションを開発、テスト、使用することさえできます。Microsoft では、ファーム全体のソリューションであっても、サンドボックス ソリューションの機能をできるだけ多く使用して設計し、ファーム ソリューションに必要最小限の機能のみを配置することをお勧めします。
アプリケーション全体をサンドボックス ソリューションとして展開できない場合は、変更を収集するサンドボックス ソリューションを、サイト コレクションから収集したデータを要求する外部 Web サイトと組み合わせることができます。約。(サンドボックス ソリューションには 1 つの大きな制限があります。外部のサイト コレクション内からWeb 要求を行うことはできません。外部からのみサイト コレクションにアクセスできます。)
--- フェルダ