7

私は、経験豊富な ASP.Net 開発者向けに SharePoint 2007 (そして最終的には 2010) のトレーニング資料をまとめようとしています。SharePoint を何年も使用してきましたが、最初に最悪の障害点がどこにあったかはよく覚えていません。 Googlable SharePoint コンテンツの量が 2 年前よりも桁違いに多いことに言及してください。

とはいえ、SharePoint のどの概念が最も把握しにくいのでしょうか?また、SharePoint のどの部分が難解で、初心者の SharePoint 開発者が飛び込んできただけでわかりにくいのでしょうか?

4

7 に答える 7

8

把握するのが最も難しいものの私のリストは次のとおりです。

  • コードアクセスセキュリティおよびその他すべてのセキュリティ機能
  • サイト/アプリケーションページとカスタマイズ/非カスタマイズページの違い
  • クエリとすべての定義の両方でのCAML
  • 車輪の再発明をしないようにSharePointにすでに含まれているもの

  • コントロールをあきらめる。

    ページ上にあるWebパーツと、それらがどのように接続されているかを制御することはできません。それらを再利用できるようにするだけです

    サイトにあるリストやそのリストに含まれるフィールドを制御することはできません

  • 複数の言語のサポートの欠如
  • SPContext.Currentから取得した場合は、SPWebとSPSiteを破棄しないでください。
  • コントロールの委任

新しいが理解しやすいと思われるその他の事項は次のとおりです。

  • ソリューション/機能
  • マスターページのすべてのプレースホルダー
于 2009-09-15T07:18:38.227 に答える
7

*コントロールの欠如*

Per Jakobsen が言及しているように、これが重要な問題です。移動中...

  1. 好きな場所で .aspx および .master ファイルにアクセスして編集することはできません。ゴースト解除、サポートなどの結果があり、期待どおりに機能しないことがよくあります. SharePoint がページを構成する方法を十分に理解することが重要です。

  2. データベースに直接クエリを実行する (サポートされ、信頼できる) 方法はありません。これは、専用の適切に設計されたデータベースの設計/操作に慣れている ASP.NET 開発者にとって非常にイライラさせられます。CAML クエリは、十分に最適化された SQL クエリの機能に代わるものではありません。

  3. (2b のほうが多い): リスト間のリレーショナル データのサポートが不十分です。エンタープライズ アプリケーションとしては奇妙です。

  4. 少し話が逸れますが、HTML マークアップと CSS は 2003 年には悪夢であり、2007 年にはそれほど良くはありませんでした。作業するのは面倒で、美しくもありません。Web 標準とベスト プラクティスに完全に準拠したサイトを作成するには、多大な努力が必要です。

要約すると、通常は "SharePoint の方法" で行う必要があります。多くの場合、これは純粋な ASP.NET 開発者が好む最も効率的またはエレガントな方法ではありません。開発者はエレガンスを好み、制御を放棄することを好みません。

また、製品全体に落とし穴があります ( Sean は重要な問題について言及しています)。それらを知り、理解する唯一の方法は、SharePoint を知ることです。これは大きな製品です。

ASP.NET 開発者が WSS を使用しない理由 SharePointDevWiki で。

于 2009-09-15T08:36:18.430 に答える
7

グレッグ、

私の経験では、適切なオブジェクトの破棄 (アンマネージ COM オブジェクトのSPRequestラッパーを参照するSPWebおよびSPSiteオブジェクト) に関連する発行は、よくある問題であり、多くのスケーラビリティ、パフォーマンス、およびその他のコーディングの問題の原因です。Microsoft は、問題の規模とこの分野での開発者の混乱の程度を認識すると、大規模なガイダンス記事 ( http://msdn.microsoft.com/en-us/library/aa973248.aspx ) を作成し、SPDisposeCheck ツールを開発しました。 ( http://code.msdn.microsoft.com/SPDisposeCheck )。

それは、「飛び込んだばかりの初心者のSharePoint開発者には明らかではない」という私の投票です:-)

それが価値があるもののために！

于 2009-09-15T01:22:21.380 に答える
4

SharePoint に既にあるものを再発明する必要はありません。私はこれに投票します。

于 2010-01-20T14:18:08.927 に答える
3

Per hascovered は、私にとってほとんどのポイントをカバーしましたが、さらにいくつか追加します。

  1. SPContext - イベント レシーバー内の SPContext.Current または Properties オブジェクトなど、概念的なコード実行の概念。

  2. コンテキストに続いて、コードが誰として実行されているかを理解し、コードが実行できるアクション (昇格 (特権の昇格)、偽装 (トークン)、および実行 (Web サービス/イベント受信者)) を理解することも重要です。

  3. エラー処理 - 「エラーが発生しました」という唯一のエラーが表面化すると誰もが悲鳴を上げるため、SP ログとエラー コードを理解することが重要です。これは、腹立たしい XML エラーを追跡する無駄な時間を削減するために重要です。

  4. Visual Studio ツール - WSPBuilder、Sharepoint 用の VS ツールなど。統合サイクルを短縮することで、展開とデバッグの手間を軽減します。

于 2009-09-16T09:19:57.837 に答える
0

実世界のアーキテクチャと実装に関連するすべて。私は開発者ですが、公式のITサポートを待たずに、仮想環境で可能な限りクライアント環境を近づけたい場合は、手を汚す必要があります。イントラネット、インターネット、エクストラネット、混合認証メカニズム、代替アクセスマッピング、ホストヘッダー構成などを備えた小さなファームを作成してみてください。これは完全に専用の仕事ですが、中規模から大規模の実装を開発する場合は、深く掘り下げる必要があります。

于 2011-01-28T14:44:04.263 に答える
0

SQL Server のレポート サービスを使用して、実際の問題についてレポート/ダッシュボードを作成し、sharepoint サイトに表示します。オンラインで見つかった例/チュートリアルの数ではありませんが、この問題はまだ不十分です (推測します)。

于 2010-01-27T17:26:09.940 に答える