asp.net Webパーツは排他的な開発に十分ですか？
私の仕事では、開発の大部分を最終的にSharepoint 2010に移行する予定であり、Sharepoint2010はasp.netWebパーツをサポートしているため、すべての新しい開発を排他的に移行する必要があるという質問がありました。 asp.net Webパーツ？
また、プリズムがこれらすべてにどのように影響するかについても尋ねられました。 （それが何であるかわからない）
現在、ほとんどがクライアント/サーバーベースの場所ですが、SOAフレームワークに移行しています（ゆっくりですが）。
これは良い考えですか？ WPFとWinformsのいくつかのアプリをサービスにヒットさせる方がよいのでしょうか、それともWebパーツのみにアクセスする必要があるのでしょうか。この動きをすると、何を見逃すのでしょうか。
Webパーツとサービスアーキテクチャをうまく作成すると、SharePointと統合することのすべての利点を備えたデスクトップアプリケーションの多くの利点を備えた非常に優れたソリューションになります。従来のMVCを使用する代わりに、サービス指向のアプローチをお勧めします。ほとんどの作業は、サービスとフロントエンドjQuery（またはそれがあなたのものであればextjs）で行われます。
問題は、SOAコーディングおよびデプロイメント中の一時的なギャップとして、既存のクライアント/サーバーアーキテクチャと統合することです。特にWinformsアプリケーションがサービスへのアクセスを必要とするため、損失はほとんどありません。とにかく機能するレイヤー（ここでは仮定を立てていますが、あなたの説明からはそのように聞こえます）なので、SharePointへのアクセスを保証できます（ここでも、ネットワーク構成についていくつかの仮定を行います）。
全体として、Sharepointにすべての機能がシームレスに統合されたワンストップショップがあり、1つの場所にあることは、エンドユーザーにとって最良のシナリオのように思えます。確かに、特にこの種の開発に慣れていない場合は、JSでフロントエンドをコーディングするのは少し難しいです。学び、それを正しく行うための努力は、少なくともIMEのスペードで報われます。
免責事項：これはすべて、投稿と同様の状況にある人々に関する私の知識に基づいた、アプリと環境に関する多くの仮定に基づいています。あなたの状況は、私が知らない方法で根本的に異なるかもしれません。幸運を！