カスタムASP.NETアプリケーションからSharepointサービスへの移行

Question

当社には、顧客情報データベース用のASP.NETアプリケーションがあります。アプリケーションは小規模に開始されましたが、適切な設計が行われていません。今度は、新しいバージョンのアプリを開発する必要があります。これは、基本的にはゼロから設計して実装することを意味します。同社は今後Microsoft Sharepoint Servicesを利用することに関心があり、この顧客データベースアプリケーションを使用してMicrosoft SharePoint Servicesを試用することが提案されています。

だから私の質問は以下のとおりです。

は、WSSが適してデータベース駆動型アプリケーションの何かか？ほとんどの場合、アプリケーションはデータベースに対してCRUD操作を実行し、レポートを作成します。

Answer 1

私は必ずしもGregが想定しているかもしれないSharePointリストにデータを入れることを推奨しないという点で私はGregに同意します。しかし、私の短い答えは "多分"でしょう。それはあなたのニーズに対応する必要がありますので

ここで長い答えはだ...

のSharePointは、ASP.NET上で実行されます。 SharePoint内にあるASP.NET Webページを作成してデータベースにアクセスしたり、データベースにアクセスするSharePoint内に存在するWebパーツを記述したりする可能性があります。

データを読み込み/取得するためのBDCが考えられますが、MOSS Enterpriseが必要でCRUDのCUD部分を提供しません。 CorasWorks DITのような他のツールも役に立ちますが、私はカスタムWebパーツやページがあなたのために行く方法だと思っています。

許可やSharePointリストデータ、プロビジョニング、検索などとデータの統合など、SharePointから多くのメリットがあります。実際には、SharePointが多くの利益をもたらす。

Answer 2

短い答え：いいえ。

長い答え： 任意のコラボレーションはありますか？データのサポート文書？ワークフロー？そうでない場合、SharePointを介してホストする理由はまったくありません。多くの利益を得ることはできません。リストの何リレーショナルな側面が存在しない - - ノー入社、無カスケード更新/削除は、などこれはよい

また、SharePointリストがテーブルのようなに見えるかもしれないが、そうでないことを心に留めておきますデータのレポートがアプリの大きな部分を占める場合は問題になります。

外部でデータを保存してSharePointに読み取り専用のリストとして表示することはできますが、他のSharePoint機能を使用していない場合でも、多くのフープでジャンプしています。

Answer 3

カークはとにかくパンチに私を殴り、私が持っているであろうよりも、それは良く言った:)

を考慮すべきもう一つは、あなたのプロセスにおけるワークフローのpossiblityです。たとえば、新しい連絡先が追加されたとき（フォローアップコールなど）にプロセスを開始する必要がある場合、SharePointは大きなメリットをもたらします。

おそらく、ハイブリッドソリューションが適切でしょう。あなたのCRUDとSharePointの統合のためのカスタムアプリケーションで、意味を持ち価値を提供します。

SPを使用するためにSPで構築するのはおそらくお勧めできません。

Answer 4

私たちはASPを持っています。NETアプリケーションは、SharePointの機能をほとんど使用していませんが、SharePointのセキュリティモデル、ナビゲーションWebパーツ（私たちはCorasWorksを使用しています）、統合されたReporting Services、およびワークフローを活用しています。少なくとも、SharePoint機能はいつか使用するために用意されています。

すべてのアプリケーションデータは、独自のSQL Serverデータベースにあります。 SharePointコンテンツデータベースには何も格納されません。