2

残念ながら、SharePoint 2013 を基本データベースとして事実上使用しているアーキテクチャを実装する必要があります。（あなたがそれを拾わなかった場合に備えて、私の選択ではありません）。サーバー上に Asp.Net MVC ファサード アプリケーションがあり、SP と他のいくつかのデータ ソースからのデータの構成を処理し、次に JavaScript SPA をクライアントとして処理します。もう 1 つの問題は、クライアントがオフラインで作業できる必要があることです。そのため、IndexedDB を使用してオフライン アクセス用のデータを保存する必要があります。

これは、breeze.js の完璧な使用例のようです。私の基本的なアーキテクチャは、SP から取得した型指定されていないデータをラップする MVC ファサードで強く型付けされたモデルを定義することです (object["property"] の形式で - SP クライアント側オブジェクト モデルを使用)。Breeze はこのモデルとクライアント間の同期を処理し、必要に応じてエクスポート/インポート機能を使用して IndexedDB にデータをキャッシュします。

ここまでは順調ですね。しかし...そよ風サイトのSOAの例はまだ開発中です（そして私にとって、これは基本的にSOAアーキテクチャであり、各SPリストは構成されるべきサービスです）。私が見つけることができる最も近いものはNoDBサンプルですが、これはクライアントのメタデータをハードコーディングします。MVC モデルで関係と検証を確立し、それらをクライアントに渡して、両方の場所で同じ宣言から検証を実行できるようにしたいと考えています。

これは可能ですか？もしそうなら - どのように？そうでない場合、誰かが回避策やより良いアイデアを持っていますか? 私はすでに、モデルを 2 つの別々の場所 (ファサードと、暗黙のうちに SP リストの構造) で定義することに甘んじています。クライアントで3回目の実装を避けたいと思います。私は Breeze.js が SP REST エンドポイントと直接やり取りすることにオープンですが、https: //stackoverflow.com/a/15364503/1014822 からの私の理解は、実装に欠陥があり、必要なメタデータを公開していないということです。

解決策：以下の受け入れられた回答に基づいて、次の解決策にたどり着きました：

1) SP ListData.svc エンドポイントからサービス参照を生成し、edmx クラスとプロキシ クラスを作成します。

2) 私のリポジトリで ContextProvider を拡張し、次のBuildJsonMetadataようにオーバーライドします。

protected override string BuildJsonMetadata()
{
    XDocument xDoc = XDocument.Load(HttpContext.Current.Server.MapPath("PATH_TO_EDMX"));
    String xString = xDoc.ToString();
    xString = xString.Replace("DATA_SERVICE_NAMESPACE", "APP_NAMESPACE");
    xDoc = XDocument.Parse(xString);
    var jsonText = CsdlToJson(xDoc);
    return jsonText;
}

3) Breeze.js をわずかに変更し、12383 行を編集します。

var schema = metadata.schema || metadata["edmx:Edmx"]["edmx:DataServices"].schema;

(おそらく、xDoc のルート ノードではなく子孫を選択することで、ContextProvider でこれを修正できたはずです)

4) - オプションで、@Christoff の非常に便利なT4TS.ttテンプレート スクリプトを使用して、サービス プロキシ クラスから d.ts を生成し、簡単に読み込まれるデータのタイプ セーフを確保できるようにします。

これまでのところ、この設定でうまくいっています。SP をデータ ソースとして使用して、メタデータを使用して基本的な CRUD を実行できます。

4

1 に答える 1

3

v 1.2.7の時点で、Breeze のメタデータ スキーマが文書化されており、Web サービスから返されるこのスキーマに準拠する json オブジェクトが Breeze によって受け入れられるようになりました。

--- 以下、以前の投稿

来週かそこらで任意のサーバー側メタデータを公開する方法を文書化する過程にあり、その後すぐに任意の Web サービスを使用する方法の例をいくつか示します。関連するいくつかの小さなコード変更もあります。

当面、これらのドキュメントが完成するまでの最善の回避策は、クライアントでメタデータを作成し、jsonResultsAdapter を使用してサービス呼び出しの結果を「エンティティ」に整形することです。クライアントで作成するメタデータは、最終的にサーバーで作成してクライアントに送信するメタデータとまったく同じになります。

お役に立てれば。

于 2013-03-19T17:21:36.083 に答える