3

従来の ASP および ASP.NET 2.0 テクノロジで記述されたカスタム ビルドの Web アプリケーション (外部および内部の両方) が多数あります。内部ユーザーは、これらの Web サイトにファイルをアップロードできます。ファイルは、外部ユーザーが表示できます。場合によっては、外部ユーザーもドキュメントをアップロードできます。スクリーンショット1は、既存のアーキテクチャについての簡単なアイデアを示しています。

  1. 内部ユーザーはドキュメントを にアップロードしますcustom web applications。これらのドキュメントは、Web アプリケーションで定義されたフォルダー構造に保存されます。

  2. 誰がドキュメントにアクセスできるかなどのメタデータとユーザー権限はSQL Serverデータベースに保存されます。

  3. にアップロードされている同じドキュメント セットが にcustom web applicationsも存在しSharePointます。ただし、カスタム Web アプリケーションは SharePoint を認識しません。そのため、ユーザーはそれらを SharePoint からダウンロードしてから、カスタム Web アプリケーションにアップロードする必要があります。現在使用していSharePoint 2010ます。

  4. 外部ユーザーは、ドキュメントをカスタム Web アプリケーションにアップロードすることもできます。ドキュメントのメタデータとユーザー権限は、ドキュメントをアップロードしているユーザーに基づいてデータベースに保存されます。

スクリーンショット #1 :

1

スクリーンショット # 2は、私が達成しようとしているアーキテクチャを示しています。SharePoint の開発はほとんど行っていません。ほとんどの場合、SharePoint Web サービスを使用していくつかのリスト コンテンツを取得しましたが、それ以上のものはありません。将来のカスタム Web アプリケーションは、ASP.NET MVC を使用して作成される可能性があります。スクリーンショットの後に質問を見つけてください。

スクリーンショット #2 :

2

ここに私の質問があります：

  1. internal usersSharePoint で引き続きドキュメントをアップロードして維持したいと考えています。ユーザー セキュリティ モデルは、SQL Serverデータベースで既に定義されています。ユーザーがカスタム Web アプリケーションからドキュメントを表示できるユーザーを選択できるように、このセキュリティ権限は SharePoint ドキュメント プロパティで使用できる必要があります。どうすればこれを達成できますか？SQL Server のユーザー権限情報を SharePoint にコピーする必要がありますか?

  2. SharePoint Web ServicesまたはBusiness Connectivity Services (BCS)、ドキュメントとその関連情報を SharePoint から取得するのに役立つと思います。このシナリオに適しているのはどれですか?

  3. カスタム Web アプリは、ドキュメントのコミットされたバージョンのみを表示する必要があります。ユーザーが SharePoint でドキュメントをチェックアウトして変更を加えた場合、チェックアウトしたバージョンのドキュメントは外部ユーザーに表示されないようにする必要があります。それは可能ですか？

  4. 誰かがこのアプローチを試しましたか? このモデルに落とし穴はありますか? この設計にパフォーマンス上の懸念はありますか?

  5. ASP.NET MVC を使用して既存のアプリケーションを書き直した場合、この設計は妨げになりますか?

  6. カスタム Web アプリケーション ( ASP.NET Web Forms/ ASP.NET MVC) 内で SharePoint 検索機能を利用することはできますか? つまり、カスタム Web アプリから検索条件を送信し、SharePoint に検索を実行させて、結果をカスタム Web アプリに返すことはできますか?

ご意見をお寄せいただきありがとうございます。

前もって感謝します。

4

1 に答える 1

2

質問1

詳細がないとなんとも言えません。したがって、現在、認証ストアに Active Directory を使用していると仮定します。これは、SQL Server がロールのリストを定義し、これらのロールにメンバーシップを割り当てたことを意味します。割り当てられたメンバーシップが AD ユーザーまたはグループに割り当てられていると仮定します。これが本当なら、SQL Server から SharePoint にアクセス許可をプッシュする正しい道を進んでいると思います。SharePoint の API は必要なことに対応しますが、SharePoint にはアクセス許可の変更を同期するメカニズムが組み込まれていないため、大量の配管コードを作成することになります。同期を処理できる製品を調査することをお勧めします。

質問2

SharePoint Web サービスまたは SharePoint クライアント アクセス サービスは正常に動作するはずです。プロキシ パターンを使用してアプリケーションを SharePoint 呼び出しから分離することを強くお勧めします (これにより、アプリケーションを SharePoint のアップグレードや潜在的なコンテンツ管理サーバーの変更から分離できます)。

質問 3

はい、可能です。SharePoint Server (SharePoint Foundation ではない) の発行機能を使用している場合は、現在発行されているバージョンを簡単に特定できます。それ以外の場合は、クエリを実行するサービス アカウントをセットアップして、発行済みバージョンのみを読み取れるようにする必要があります。その後、SharePoint はクエリを自動的にトリミングします。

質問 4

個人的にはこの設計を試したことはありませんが、コンテンツ管理ドメインを作成し、その上に抽象的なサービス レイヤーを配置するというコンセプトがとても気に入っています。規模の問題は、SharePoint とアプリケーションの構成方法によって異なります。あなたはそれを正しくまたは間違って行うことができます。2 つの間の深さの答えは、ここではカバーできません。私の 1 つのアドバイスは、サービス インターフェイス (キャッシュ、キャッシュ、キャッシュ) でのキャッシュを確実に計画することです。

質問5

サービス層として実装する場合はそうではありません。リポジトリ パターンを使用してサービスを呼び出し、モデルのエンティティを返すだけです。

質問6

はい。検索は API を介して公開されるため、サービス層にもラップできます。

幸運を祈ります。詳細については、私に直接お問い合わせください。

于 2011-06-05T18:34:52.977 に答える