シェアポイントプログラミングはどの程度良い/悪いですか？
今日、SharePoint開発者としての職に就くことができました。私の友人の一人は、シェアポイントは大きな混乱であり、私がやりたいことではないと言っています。
SharePointを使用した経験/考えは何ですか？
ここで少しトレンドに逆らうつもりです。 SharePointは開発プラットフォームであり、シンプルでシンプルだと考えています。 IIS、ASP.NET、SQL Server、Windows Workflowなどの他のテクノロジーを利用しているため、車輪を再発明する必要はありません。配管やシステムレベルのコードを心配するのではなく、ビジネス上の問題の解決に集中できます。
誤解しないでください、SharePointには荷物が付属していますが、スリングコードだけでなく、現実のビジネス上の問題を解決したい場合は、たくさんのことができます。私は、プラットフォームがWSSv3でどれだけリッチであるかに常に驚いています-これは無料です。
マイクロソフトのテクノロジーと連携したい場合は、SharePointが定着し続け、より良くなり、より一般的になることを理解する必要があります。現在のバージョン（v3-WSSv3/MOSS 2007）には、AJAX、ソーシャルネットワーキング、およびその他の機能/技術がありません。v4バージョンは間近にあり、これらの領域で改善する予定です。 。
このスレッドで読んだいくつかのネガに関しては：
AJAXツールキットを使用するSharePointに存在するWebパーツを作成したため、私の同僚がいます。1人の同僚がSilverlight Webパーツで非常に活発です。
はい、Windows Server 2003/2008で開発する傾向があります。これは私を煩わせず、インストールと設定にあまり時間をかけません。開発環境に仮想マシンを使用することもありますが、それが苦痛になることもあります。
ただし、私ができることは、開発の代わりにいくつかの設定を行うことです。承認、完了。プロビジョニング、完了;行レベルのセキュリティ、完了;基本的なUI CRUD、完了;複数のフロントエンドへの展開が完了しました。検索、完了。今、私はビジネスの問題を解決することに集中する時間があります。
SharePoint開発を行う場合は、すぐに開始する必要があります。 Microsoft Windows SharePoint Server 3.0内 を強くお勧めします。これにより、開発者がSharePoint内でできること/すべきことの核心をつかむことができます。
それが価値のあることのために、私は20年以上にわたり、いくつかの異なる言語とテクノロジーでUnixとWindowsに取り組んでいる開発者です。私はベータ版の頃からSharePoint v3に注力してきましたが、選択した方向に満足しています。
私はすべての肯定的な反応に驚いています。コードでマークアップを作成しても構いませんか？ HtmlWriter.BeginTag（ "br"）（または、HtmlWriter apiを知らなくて申し訳ありません）のように。再配布可能なWebパーツを作成するためのベストプラクティスと考えられています。
Ajax Toolkitはどうですか？おっと、立ち入り禁止です。ヘッダーにdoc-typeがないため機能しません。
ラップトップでWindows Server 2003を実行していますか？もちろん、Sharepointは他のものでは動作しません。
プラットフォームを守る人々を理解していますが、Sharepointで何らかの仕事をしなければならなかったが、それ以上はしません... Sharepointでの開発は私の人生で最悪の開発経験だと言えます。今、私はこれまでの選択にかなり注意を払ってきたので、最悪の経験ではありませんが、それはそこにあります。あるいは、別の言い方をすれば、SharepointよりもPHPでの作業を好むでしょう。
私の小さなWebショップは、数年前にSharePointを簡単に受け入れました。コンサルティング、カスタマイズ、トレーニングなどを行いました。箱から取り出したものがたくさんあることは事実です。しかし、全体的な経験は非常に否定的であり、振り返ることはありませんでした。
- 私たちがそれについてトレーニングしたユーザーはユーザーインターフェースを絶対に嫌い、それで間違っていることを修正できないのは非常にイライラしていました。
- Sharepointのビジュアルプレゼンテーションのカスタマイズは、気弱な人向けではありません。マイクロソフトでCSSを書いた人の無能さは恐ろしいだけです。私にはまだ悪夢があります。
- なんらかの理由で、彼らはそれを単に園芸品種のWebアプリとして設計しなかったので、開発環境をセットアップすることは大きな苦痛になります。
一般的に、SharePointは多くの点でその約束を欠いていますが、それは単なる神秘的なものです。
顧客向けに独自のソリューションを展開することに戻りました。彼らはその配置に非常に満足しており、私たちもそうです。
良い============================ [=] ===悪い
- セットアップ/管理/更新は苦痛です
- 開発/デバッグは苦痛です
- ドキュメントは冗談です
Sharepoint IS巨大な混乱。
- 生成されたマークアップは、私が見た中で最悪です。
- そのマークアップを長くするのは等しく悪いCSSです。
- 神は、SharePointアプリケーションのクライアント側の機能を再構築または拡張しなければならない魂をmercれんでいます。
- プラットフォーム全体は、優れた建築設計に直面します。
- トランザクションがないため、データの整合性はプラットフォームの大きな問題です。
- APIは驚くほどバグが発生しており、APIを操作してからWebを探し回ってデータ整合性の問題をさらに悪化させるバグに遭遇するまで1時間もかかりません。
- プラットフォームで適切な単体テストを行うことは非常に困難です。
- プラットフォームは大きく、「すべて」が詰め込まれていますが、Sharepointが行うすべての機能は不十分です。他のフレームワークやプラットフォームを簡単に見つけることができ、より良い仕事をし、あなたやあなたのクライアントの要件にぴったり合うでしょう。
- 学習曲線は急勾配であり、プラットフォーム（特にAPI）のドキュメントが適切であれば問題ありません。
- ブラウザの互換性、SharepointはIEのみ（その恐ろしいマークアップ、CSS、およびjavascriptに起因）。
プラットフォームは金をmakesけますが、金makingけの仕組みとしてではありません。 Sharepointの開発者のスキルはまれであり、それらのスキルを持っている人は給与が高くなります。クライアントは、Sharepointがすべてに最適であることをクライアントに納得させるために、Sharepointのカスタム開発および開発ハウスに歯を介して支払います。
私の意見では、Sharepointは開発プラットフォームではなく、金makingけプラットフォームです。
編集：私も11を追加するのを忘れました。これはあなたが今まで見たことがないようなリソースピッグです。
SharePointの最大の不満は、最新のリリースであっても、ドキュメントに注意を払っていないことです。文書化されていないAPI呼び出しが非常に多くあります。この回答を投稿するだけで血圧が上昇するのを感じることができます。
2003年のベータ版以降、KirkもSharePointと連携していて、今でも気に入っています。もちろん、何かをもっとよく考えてほしいと願うことはできますが、ほぼすべてのエンタープライズ製品について言えることでしょう。私にとって、プラスは、SharePointプラットフォーム上でソリューションを構築することに関して、マイナスをはるかに上回っています。
開発者として、SharePointのトップ5の良い点と悪い5つの点を共有しましょう。
SharePointの優れた5つのポイント
- これは包括的なプラットフォームです。企業のイントラネットやエクストラネットのような、フル機能の標準化されたスケーラブルで高可用性のWebソリューションの開発と展開が非常に高速になります。
- 大きな勢いがあります。マイクロソフトは改善を続けており、リリースごとにはるかに良くなり、コミュニティは大きく成長し、オンラインリソースは大きく成長し、ますます多くの本が出ています。多くの素晴らしい無料アドオンと優れたサードパーティ製品がすべて登場します時間、そして行くべき素晴らしい会議もあります。
- ソリューション、機能、Webパーツ、テンプレート、コンテンツタイプなどに独自のものをパッケージ化できる非常にモジュール式のプラットフォーム。
- .NET、ASP.NET、IIS、SQL Serverなどの標準的なMicrosoftテクノロジーを活用します。特定のスキルセットにとらわれることはありません。
- 現在の雇用市場では、.NETスキルよりも.NET + SharePointスキルの方がはるかに優れています。 SAPの経験がある、またはBIの専門家であると言っているようなものです。
SharePointのトップ5悪いこと
- 急な学習曲線。すでにC＃と.NETが得意であっても、優れたSharePoint開発者になるには少なくとも2年かかります。プラットフォームのすべての概念を理解するのに最初の1年が必要で、それからさらに1年はそれらの概念に本当に慣れる必要があります。
- 不十分な開発ツール。 Visual StudioはSharePointについてほとんど何も知りませんが、VS 2010でこれが大きく変わると聞いています:-)
- 最新のクールな.NET機能を常に使用できるとは限りません。 SharePointが.NETプラットフォームチームから最新かつ最高のものを採用するには、常に数年かかります。 LinqとAJAXについて考えてみてください。 SharePoint 2010が.NET 4.0をサポートするかどうか/いつ参照するのか興味があります。
- 多くの場合、プラットフォーム内の風変わりな問題/不整合に対する回避策を見つける必要があります。
- APIの変更。少なくとも、これはSPS 2003からMOSS 2007に移行する痛みでした。SharePoint2010への移行がスムーズに進むことを望みます。
3か月前、SharePointについて何も知りませんでした。それ以来、会社の新しいサポートサイト用にいくつかのカスタムWebパーツを作成する必要があり、あなたの友人に同意する必要があります。これは大きな混乱です。
最初は、コーディングをまったく行わずにプラットフォームを使用してどれだけのことができるかに感銘を受けました。しかし、自分のものを適切に機能させるのはいらいらしていました。以前に書いたユーザーコントロールを組み込むことを試みましたが、これは通常のWebアプリではうまく機能しましたが、重要な部分は、SharePointでまだ機能しません。私は何とか回避策を見つけましたが、その過程で2週間を失いました。
また、開発環境が実際にSharePointを実行しているマシンでなければならず、Windows 2003/2008の下で実行する必要があることを知ることは失望しました。既存のシステムに仮想マシンをセットアップする必要がありましたが、これは大したことではありませんが、克服しなければならないもう1つのハードルです。
全体として、それはあなたがやろうとしていることに対してあまりにも混乱させるように見えました。実際の開発ではなく、インストール、構成、および展開に多くの時間が費やされるという意見に同意します。 2010年のバージョンの方が良いかもしれません。それは確かに私が一緒に働くことを楽しみにしている製品ではありません。
私は、まもなく終了するSharePointプロジェクトに3か月かかります。
エラーログを調べて、さまざまなSharePointコンポーネントがMSのように機能しない理由を解明しようと日々努力しています。開発業界の多くの人は、ドキュメントを「...私が見た中で最悪」と見なしています。 MS関連サイトで役に立つものを見つけてください。
多くの「ソーシャル機能」は、悪名高くバグが多く設定が難しいUPS（User Profile Service）に依存しています。グーグルで見るとわかります。私のプロジェクトでは、UPSをまったく動作させるのに複数の開発者とEEの博士号が必要でした。これはすべてWebサービスです！継続的な安定性の問題により、同社は最終的に「このプラットフォームを信じている！」と宣言したSharePointの著者を雇ったという。ああ、そうですね。彼はそれを言うためにいくら払われているのだろうか。しかし、MS MS Cummulative Updateが追加されるたびに、少なくとも開発環境では、UPSは実行可能に近づいていきます。完全に機能しなかった最初のリリースから長い道のりを歩んできました。
Active Directory、IIS、ForeFront Identity Management Services、SQLServer、およびServer2008の設定の構成に多くの時間を費やします。これらの設定のほとんどは互いに競合するため、回避策を探すためにSharePointブログに十分な時間を費やす準備をしてください。実際、ほとんどのSharePointブログは、SharePointを機能させるため、または少なくとも基本的なWebサイトの機能を有効にするために、回避策とハッキングに専念しています。事前に構築された機能を備えたプラットフォームのポイントは、作業負荷を増やすのではなく、減らすことだと思いました。管理者やブログの探偵をプレイせずにコードを配置したい場合、これはあなたのためのプラットフォームではありません。
他の場所で述べたように、開発要件は非常識です。 SharePoint Server（製品のフルバージョン）は、Windowsサーバー上でのみ実行できます。私にとって、これは仮想マシンを意味します。 8GBのRAMは、本当に必要最低限です。適度に高速な開発環境を構築するためだけに、コアi5、16GB、およびSSDを購入することになりました。これはWeb編集であり、ビデオ編集ではありません。
運用環境でSharePointをやや安定させることができる幸運な場合、エンドユーザーは5秒のページ読み込み、ほとんどすべての種類の要求に対する応答時間が遅くなり、最近では最も直感的でないUI計算履歴。 SharePointの大きな魅力の1つは、さまざまな種類のWebパーツを追加するか、SharePoint Designerを使用してページの構造を実際に変更することにより、Webページをその場で編集できることです。これにより、経験豊富な開発者が多くのトラブルに巻き込まれる可能性があるため、この機能の対象と考えている技術者以外のユーザーは死亡します。彼らは、非常に有用で有益なGUIDを提供する相関IDエラーのコーラスに遭遇します。
この混乱に関しては、開発者とエンドユーザーの両方がゆるんでいます。 SharePointの唯一のメリットは、オープンソースの必要性を信じさせることです。
PS-スペルや文法を攻撃しないでください。私は英語専攻ではありません。
私はまともな.net開発経験があり、SPで3か月、これまでの私の経験：
良い：
SPは、単純なデータモデル、できれば読み取りが多いアプリケーションに適しています。ユーザー/管理者が構成のみで達成できることです。データ構造をその場で変更し、外観を変更します。そして感じます。「私の本」のようなもののための素晴らしいプラットフォーム..
悪い：
しかし、SPがつまずいて落ちます（あなたに）。たとえば、非自明なロジックが必要な場合、特に外部キー関係を介した集約関数が必要な場合、作業が難しくなります。もちろん、トランザクションの欠如。データの整合性を維持することが問題になる可能性があります。特定のプロジェクトでの作業を検討する際には、このことに注意してください。
コンパイル時のサポートはほとんどありません。タスクの大部分には、文字列として名前で呼び出すことで検索されたリソースの混乱が含まれます。それは「柔軟」で「シンプル」と考えることができますが、私の好みにはあまりにもエラープルーンであり、開発が遅くなります。もちろん、これはSPのことだけでなく、MVC/webformsは強く型付けされた世界に向かってより簡単にプッシュできるように思われます。
マネージドワールドが好きな場合は、SPの大部分が非マネージドコードであるという事実に対処し、「HResult 8000072F」のような例外を提供します。失敗しました。
展開とバグの再現性により、非常に多くのイライラする日が生じました。 WSSはマシン全体を取得し、アプリの実行に必要なファイルはDB、ファイルシステム（および多くの場合GAC）に分散しています。プロジェクトを基本的に分離するには、多くの異なるVMで作業することを期待してください。
ツールのサポートは非常に貧弱です（VS 2010を試していません）。コマンドラインとスクリプトを使用して友達になることを期待してください。デバッグの経験が遅いことを期待してください。ユニットテストは非常に難しいです。
私の個人的な結論： SPはニッチですが、.Netプログラマーが楽しめるプラットフォームではありません。ユーザーエクスペリエンスには時々「WOW」がありますが、開発者の経験はそうではありませんでしたが、これは「急な学習曲線」の話かもしれませんが、たぶんそうなっているだけかもしれません。
SharePointは時にイライラすることがあります。マイクロソフトによると、これは「成熟製品」であるため、何か間違ったことをすると、「エラーが発生しました」や「アクションを完了できません」などの素晴らしいエラーが発生します。 CAMLは大きな忍耐を必要とするものです。それに関するドキュメントはあまり良くありません、そして、あなたは愚かな構文エラーについて多くの時間を浪費することができます。
全体として、それはまともなプラットフォームですが、おそらくあなたの同僚よりも早く白髪になります。
請求書を支払う（良い？）方法です。
SharePointはv2製品です... v3は2010年にリリース予定であり、MSの歴史上最も急速に成長している製品です（おそらく）。 v2はまだ成熟しておらず、開発者にとって望ましいものは間違いなく残されていますが、それに対して開発を容易にする多くのツールがあります（stsdev、1つであること）。
これは、Windows領域にとどまるとますます見られるものです。これは強力なプラットフォームであり、将来は非常に有望に見えます。
開発者の観点からは、ほとんどのWindowsベースのアプリケーションがそうであるように、開発者がそれに対する開発を一種の再考として考えたことに少しイライラしています。エンドユーザーが優先的に勝ちます。それは確かです。
SharePointの作業は、開発の側面がなくても、やりがいがあり、やりがいがあります。あなたは組織全体に影響を与えており、実際にビジネスの改善を支援しています。開発の側面は時々あなたを苛立たせますが、それはすべて均等になる傾向があります。
プロジェクトの実行方法によって大きく異なります-SharePointの設計内で作業すれば、多くの労力をかけずに多くのことを達成できます。それに反する要件があり、クライアントが妥協する意思がない場合、かなりイライラする可能性があります。
また、適切に設定されていない多くの環境を取得する傾向があります。ソース管理や再現可能な展開などの基本的なものでさえ、しばしば除外されます。多くの場合、インフラストラクチャの人々はSharePointを理解していないため、開発環境をネットワークに接続できないなどの問題が発生します。
ただし、これらの問題のほとんどは、自分が何をしているかを知っている関係者がいる場合、非常に簡単に解決されます。プロジェクトや環境の問題を乗り越えると、作業に適したプラットフォームになります。
公式のドキュメントは特に有用ではありませんが、利用可能な非公式のドキュメントとツールは、プラットフォームでの作業を開始してから大幅に改善されました。
他の回答から明らかなように、SharePoint開発者には多くの不満があります。
与えられたものは：
- はい、サーバー製品のWindows 2003またはWindows 2008で開発する必要があります
- 多くの開発情報は、さまざまな品質のブログから得られます
- 製品はすべての人にすべてのものになろうとしますが、現実には、製品は非常に大きく、専門分野が必要です
それは間違いなく、開発者のためにまだ成熟している技術です。開発者コミュニティとマイクロソフトから入手できる情報の量は、過去2年間で大幅に増加しました。 SharePointのパターン＆プラクティスチームからは、次のような多くのガイダンスが出ています： http://www.codeplex.com/spg
他のコメントのいくつかについては、これは、必ずしもインストールではなく、販売されたライセンスで測定された急成長しているマイクロソフト製品です！そして、はい、WSS 3.0に無料で付属している機能は非常に素晴らしいです。
「SharePoint開発」に含まれることのできる範囲は非常に広いです。 WebブラウザーとSharePoint Designerなどのツールを使用して、純粋なWebコンテンツを開発することもできます。または、カスタムASP.NET Webパーツ、Windowsワークフロー、カスタムASP.NET WebサービスおよびSharePointでホストされているページなどを書くこともできます。
SharePointには、他のシステムとの統合を可能にするすぐに使えるWebサービスがたくさんあり、一部の人々はそのAPIに対してプログラミングを「SharePoint開発」と呼ぶかもしれません。
一般的なSharePointの経験則では、表面上は、すべての人を対象にした包括的な製品のように見えます。プラットフォームは、大幅なカスタマイズなしでは特定のビジネスニーズを解決できないことを理解するために、表面をあまりスクラッチする必要がない場合があります。必要な機能の最後の10％が労力の90％を費やすこともあります！
それは、同時に最もイライラし、最もやりがいのある経験です。報酬は（少なくとも部分的に）素晴らしい給与の形で（ストレートウェブ開発と比較して）得られますが、欲求不満はあなたの側でstackoverflowとgoogleで克服することはできません。
2003年からSharePoint開発を行ってきましたが、「I FREAKING HATE SHAREPOINT！」 「すごい、それはすごい！」の瞬間によって常に相殺されます。
SharePointを行うエントリレベルの役職を提供された場合、私はそれを心から受け止めます。最もホットなテクノロジーの1つに関する実地トレーニングを受けます。
Web開発のバックグラウンドがある場合、Sharepointが開発者に提供する柔軟性の欠如に不満を感じるかもしれません。 「Webパーツ」の観点から考えるように制限されていることは、以前HTMLに少し近い記述をする柔軟性があったなら、それほど楽しいことではありません。
さらに、通常のWeb開発と比較して、構成/実装の問題に多くの時間が費やされていることがわかりました。
ただし、「箱から出してすぐに」合理的な量の機能を利用できます。
私はもともと、Webコンテンツ管理システムを構築し、ドキュメント管理システムで作業しているASP.NET開発者でした。 SharePointは、この分野で私が既にプラットフォーム上で持っていたスキルを活用して自然に進歩しました。
私はこの昨年、興味深いと思われるプレゼンテーションを行いました。
詳細については、こちらをご覧ください： http://sharepointdevwiki.com/x/HYBfAQ
SharePointプログラミングの経験が豊富であることを報告できてうれしいです。すぐに使えるマスターページとCSSはかなり悪く、APIのドキュメントのあちこちの欠如は時々非常にイライラする可能性がありますが、SharePointを開発フレームワークとして代わりに見る場合、これらはマイナーな後退ですカスタマイズ可能な有限製品。 MSの誰かが、SharePointを「モデリングクレイ」と表現し、すぐに使用可能なテンプレートは単に達成できるものの「デモ」であると説明しました。
カスタムマスタページ（ヘッダーに適切なDoc Typeを使用してひどいBackCompatを削除し、CSS1Compatを有効にするなど）を作成するか、aspxページにコードビハインドなどを設定するのは非常に簡単でわかりやすいです。要するに、純粋なasp.net 2.0のWebサイト内でできることは何でも、SharePointでも同じことができ、そのスケーラビリティ、展開手法、API、権限モデル、監査、ドキュメントストレージシステム、InfoPath統合、ワークフロー、等.
最終的には、あなたの視点に本当に依存していると思います。SharePointは、サイトテンプレートの "デモ"コレクションを備えた開発プラットフォームですか、それともあちこちでカスタマイズできる半有限製品ですか。