Sharepoint 2010 上で開発するのに適したアプリケーションと、Sharepoint 2010 上に構築すべきではないアプリケーションの種類を知りたいです。では、Sharepoint 2010 を新しい Web アプリケーションの開発プラットフォームとして採用/回避する時期はいつなのか。
SharePoint 開発スペシャリストとして、次の特徴を持つ次のエンタープライズ アプリケーションのプラットフォームとして SharePoint を選択しますか?
私は Asp.net MVC (以前の Web フォーム) 開発者であり、Sharepoint 2010 の上に通常の複数ページの半複雑な Web アプリケーション (イントラ/エクストラネット) を構築する必要があるかどうか、およびその理由を知りたいです (はいまたは番号）。
SharePoint は使いやすさ、開発、およびパフォーマンスの悪夢であると述べて、これを序文にします。堅牢なソリューションを作成するための開発者のアプローチは、丸太を転がしながらボウリングのピンをジャグリングするようなものであり、フレームワークには余分な肥大化があり、その中で高性能のソリューションを構築することはほとんど不可能です。
それにもかかわらず、基幹業務システムを利用するダッシュボードなどのイントラネット ソリューションを構築するのに非常に適しています。実際のコードを書かなくてもかなりのことができるので、チーム ルームや基本的なデータ収集活動はぴったりです。
その上に構築しないのは、静的またはサービスを提供する一般向けの企業 Web サイトです。
SharePoint の開発ツールは、2010 バージョンで大幅に改善されました。ASP.NET MVC を知っていても SharePoint を知らない場合は、アプリケーションを MVC でより速く完成させることができるでしょうが、問題はその後どうなるかです。SharePoint を使用すると、開発者以外が後で何らかの方法で変更できるアプリケーションを簡単に作成できます。
たとえば、次のことができます。
一方、SharePoint は邪魔になる可能性のある多くのものを提供し (大量のデータベース、IIS サイト、サービスなどがあります)、同じレベルのビジュアルとMVC の場合と同様に、アプリケーションを機能的に制御します。そして、単体テストはかなり難しいです。
したがって、基本的には、アプリケーションをどの程度柔軟にするか、およびどのレベルにするかが問題になります。SharePoint 2010 をすべてに使用するわけではありません。このサイト - スタック オーバーフロー - は、SharePoint が邪魔になるアプリケーションの例です。
あなたの他の質問に答えるために、あなたのクライアントがそれを望んでいるのであれば、私はそれを使用しないという非常に強い議論はありません (それとは別に、SharePoint を学ぶ必要があるため、時間がかかります)。そして、SharePoint 2010 を使って作業するのは非常に楽しいことを考えると、私は言い訳をして、それについて知りたいと思います。そうすれば、将来的には賛成または反対することができるようになります。
学習曲線が急で、Sharepoint 2007 はあまり役に立ちませんでした。箱から出てきたものを微調整するか、使用可能な環境を得るために多くの作業を行う必要がありました (空白のマスター ページ、xhtml、jquery サポートなどをサポートするコントロールとレイアウトを読み取る)。
ドキュメントや画像が豊富なシステムを使用している場合、または顧客がすぐに使用できる典型的なエクストラネット/イントラネットを急いで必要としている場合、これは優れたツールです。
そうしないと、速度を上げるための多大な努力が無駄になる可能性があります。
編集：デフォルト設定としてAsp.net。ポータル/コンテンツ管理/ドキュメントと画像の共有が必要かどうかによって異なります。オーダーメイドのアプリケーションを作成している場合は、必要ありません。リソース/ドキュメントを共有するコミュニティを作成している場合は、Sharepoints が最適です。Sharepoint 内で ASP.NET を引き続き実行できます。これが構築されているものです。