SharePointについての5つの神話

SharePointに関する議論を読むほど、「SharePoint」の概念そのものが神話と誤解の束になっていることを確信しています。 その一部は、このプラットフォームの使用を考えている人々の心の中に住んでおり、一部は（そして最も危険な）SharePointでサイトを作成し始めたばかりの人々の中にいます。 2番目の部分は説明するのがより難しい（そして今日も金曜日です）ので、私はひどく怠けているので、最初の部分について話す方が良いでしょう。



だから神話。 または妄想？ 関係ありません。 思い浮かんだ順番で説明しますが、それは神話が他の神話よりも「悪い」からではありません。

神話1. SharePointは別の惑星で実際に開発され、人の脳を破壊するために1つのUFOからヒューマノイドによってMicrosoftに転送されます。

時々、 これは本当のように思えます ;-)

神話2. SharePointは高価です。

それについてはすでにHabréで書いています。 無料のWindows SharePoint ServicesおよびWindows Internal Database（またはSQL Server Express）と共に無料のWindows Web Server 2008をプロモーション会社の一部として使用すると、サーバーソフトウェアのコストはほぼゼロになります。 このような構成に固有の制限は、小規模プロジェクトのニーズに完全に適合します。 初期段階の要件と成長の前提条件を適切に評価する必要があります。 SharePointは、ソリューションの規模の方向でも、使用する機能の面でも、痛みを伴わずに成長できるという点で優れています。



プロジェクトが大きくなると（そして、彼らが言うように収益化されると）、適切な構成を使用する必要があることは完全に論理的です。 ここでは、他のすべてのコストと同様に、ソフトウェアのコストが確実に増加します。サーバー、チャネルレンタル、そして最後にスタッフです。 最も具体的なのは支出の最後の項目ですが、しばしば別々に考慮されます。 これは小規模なスタートアップチームには許されますが、深刻な経験豊富な企業がソリューションを開発してサポートするために呼び出される人々の給与をプロジェクト予算に含めない場合、驚くべきことです。



プラットフォームとその開発ツール（現在は無料のSharePoint Designer（何かをすばやく修正するため）を含む）によって提供される利点が、そのようなソフトウェアの価格を正当化すると確信しています。 SharePoint Server（MOSS）についても同じことが言えます。 後者は無料とはほど遠いものであり、インターネットサイトのオプションではかなりの費用がかかりますが、もう一度繰り返します。構成の選択で最大限の努力を止め、実際のニーズと収入に関してプロジェクト全体を評価します。 このサイトで1日に数千ドルを稼いでいる人の口からMOSSインターネットライセンスの高額の費用を聞くのはばかげています。 繰り返しますが、コストとホスティングをほとんどカバーしない収益のあるコミュニティサイトを作成する場合は、最初にSharePointが最小構成で提供できるものについて考える必要があります。



「神話」の要約として、私は明らかな考えのように聞こえます。 すべてのサイズのプロジェクトの場合、最も基本的なSharePoint機能が提供するものについて考えることから始めます。 ストレージシステムの開発、承認、サイトインフラストラクチャ管理とレイアウトテンプレート、Officeアプリケーションとの統合、および組み込みコンテンツ展開ツールを節約する機会-これはすでにたくさんあります。

神話3. SharePointは低速であり、ハードウェアを要求します。

これは私の好きな神話です。 そして、インストールとセットアップが簡単な製品でも、特定の条件下で使用できるようにするための知識と多数のルールの適用が必要であるという事実の多くの人々の奇妙な誤解から生じました。 はい、プラットフォームには当然リソースに関して一定のオーバーヘッドがあります-埋め込まれた「普遍性」は決して無駄ではありません。 しかし、結局のところ、SharePointの要件に関して言えば、SQL Serverにコンテンツを保存する典型的なASP.NETアプリケーションほど難しくありません。 そして、それらの多くは世界にあります。 そして、それらはロードされています-すごい！ そのようなプロジェクトの場合、ソリューションを展開するだけでは誰も起こらないということです。 しかし、SharePointは、どのような条件で動作するかを推測する魔術師でもありません。 一方、彼は便利なWebインターフェースを使用して多くのことを行うことができますが、設定での選択をキャンセルしません。 SharePointのブレーキングについてもう一度呪い、次のキーワードを思い出してください。



・負荷分散



出力キャッシュ



BLOBキャッシュ



オブジェクトキャッシュ



関心のあるリンク： technet.microsoft.com/en-us/library/cc298466.aspxおよび「 SharepointをHighload Webサイトの速度に加速します 」。 「Bison」ASP.NET、投稿MissUFOの最後のセクション（IHttpModuleと厳密な最適化）に注意してください。 きちんとしたアプローチと責任ある態度で、このテクニックを使用すると、ページから本当にレーシングカーを作ることができます。



このトピックを終えて、車を購入した後の私の第一印象についてお話します。 ハンドルを握るとすぐに、車が動きの自由をひどく制限していることに気付きました。 次に、反対方向に移動しながら、曲がり角が許可されている場所、渋滞がより頻繁に発生している場所、一方通行の道路に進入する方法、入らない方法を計画して研究する必要があります。 また、ガソリン、「ウォッシュアップ」の心配、タイヤの空気圧。 運転手、知ってるでしょ？ 数ヶ月が経過しました。 不満は減り、自分の利点を理解し始めました。 数年後、私は車が動きの自由とそれからの喜びを与えると言うことができます。 徒歩で-優れた、環境に優しい、安価。 しかしゆっくり。 オートバイでも可能です。 しかし、私見は安全ではなく、気質に適していません:-)

神話4. SharePoint-大企業および企業サイト専用。

マイクロソフトはこの神話のせいにします。 一部には、SharePointのすべての「重い」機能が企業ポータルに重点を置いているためです。 部分的には、関連するマーケティング努力によるものです。



実際、今日流行している古典的なインターネットポータルやソーシャルネットワーキングサイトの開発に使用できる既製のスクリプトやテンプレートはあまり多くありません。 しかし、これを提供する多くのポータルプラットフォームはありますか？ 一方、噂によると、Microsoftはこの方向のギャップを認識しており、将来のバージョンに関連機能を含めるよう積極的に取り組んでいます。



この神話は、次のような多くの顧客の信念に由来しています。「SharePointは、あらゆる場合にテンプレートを用意する必要があります。 数日で私をウェブサイトにしてください！ SharePointで唾を吐く時だと聞いた」 面白いです むしろ悲しい。



最後に、私の経験（おそらくあなたの経験も）は、「Microsoftの既製テンプレート」の概念が深刻なインターネットサイトにあまり適用できないことを示しています。 この方向でソリューションの開発を開始します-独自のテンプレートを作成します。 そして、ここで次の神話にスムーズに移行しています。

神話5. SharePointでサイトを作成するために、Web開発者やデザイナーは必要ありません。

答えは簡単です：真実ではありません、私たちはそれを必要とし、どのように！ 投稿の1つに対するコメントで、MicrosoftはSharePointページのレイアウトの問題で近視眼的にデザイナーを無視していると読みました。 まあ、そうではありません！ デザインの使用を妨げるものは何もありません。 標準要素のレイアウトは干渉します-再定義します。 マスターページのテーブルレイアウトが邪魔です-独自のものを使用してください。 トラブルは彼から保留中のSharePointにあります。 一方、真面目なWebプロジェクトの技術は、優れたデザイナーやWeb開発者の必要性を排除しません。



私は確かに一つのことを言います。 SharePointは、すべてのチームメンバーに浸透する必要があります。 それは多くのことを可能にしますが、デザインからの期待のいくつかを尊重する必要があります。 そして、これらの期待は、ほとんどの場合、セキュリティ問題（奇妙なことに）とプラットフォームのすべての豊富な機能のサポートによって決定されます。



しかし、一般に、SharePointは、先ほど述べたように、その機能とトリックを備えたASP.NETアプリケーションです。

神話5.5。 SharePointは創造の自由を制限し、課された機能はしばしば人生を困難にします。

これは前の神話の続きですが、プログラミングエラーについて話しているところです。



多くの場合、開発者（特にロシアの開発者）は、奇妙だと思う一部のサブシステムの特殊な機能についてSharePointをscります。 リストアイテムとビジネスデータカタログの保存の2つを例に取りましょう。



リストによると、それらがデータベーステーブルのように振る舞わないという事実は戸惑いにつながります。 リクエストは多かれ少なかれ複雑で、サポートされていません。参照整合性はありません。 答えは簡単です。リストはデータベースではありません。 SharePointをデータベースのフロントエンドとして使用する場合は、そのように使用します。 リストとドキュメントライブラリには簡単なルールがあります。



1.ドキュメントライブラリには、ユーザーがドキュメントとして操作するファイルが保存されます 。 簡単そうですね。 しかし、イタリック体はしばしば忘れられ、プログラムの配布などに保存される予定です。 「ファイルボール」から離れることは良い考えですが、誰もが常識を必要とします。 別のストレージクラスは、aspxページファイルです。 それらを使用すると、通常、質問は発生しません。



2.リストには、ユーザーの集合作業の構造、情報の直接公開（記事、ニュースなど）およびファイルメタデータ（最初のルールから）に関連する情報が格納されます。 リストに何も保存する必要はありません。 大量のデータがない場合、ルールに違反する可能性がありますが、大容量の場合、パフォーマンスのギャップやデータ要求の問題をすぐに感じるでしょう。



2番目の例は、ビジネスデータカタログです。 データソースを抽象化し、それらをSharePointに保存されている既存の構造にリンクするのは良い考えのようです。 しかし、開発者は文句を言います：非常に複雑な記述形式。 答えは簡単で、BDCで具体化されたアイデアに基づいています。 複雑なXMLのような記述形式は、2つの問題を同時に解決するように設計されています。



1.必要なすべてのエンティティと操作を記述するのに十分な柔軟性を持ち、SharePointアプリケーションがデータベース内のデータを直接操作しないようにします。



2.特別なソフトウェアを使用せずに読み取りと編集が可能な読み取り可能な形式を使用します。



一部の人にとっては、あまり説得力がありませんが、明確にしようとします。 最初に、このようなデータソースプロファイルは、SharePoint Serverの側からアクセスできるようにするために、ソース情報システムの開発者によって一度作成されたものと想定されています。 これは、SAP、Siebel、Amazonサービスなどのシステムで迅速に行われました。 また、記述形式では、特に、特殊なコンポーネントを開発することなく、使用するデータソースからエンティティを検索できるようにオブジェクトを指定することもできます。



この神話を考えると、車との類推が再び思い浮かびます。



「パステルナックは読んでいませんでしたが、非難します」 経験豊富な人々の印象は、さらに歓迎されています。 ご存知のように、良いアイデアは頭に浮かぶのではなく、「頭の間に」。