SharePointまたはアプリケーション開発の基礎として（ASP.NET用）

Question

私は、これらの条件下でアプリケーション開発にSharePointを使用する必要があるPOVを持っています。

1）アプリケーションはドキュメントを使用しており、これらのドキュメントはSharePointが非常にうまく機能する（検索/インデックス作成、Outlookとの同期など）必要があります。ドキュメントバケットとリストが必要な場合はASP .NETまたはASP.NET MVC。

2）アプリケーションは、ワークフローまたはカスタムワークフローを使用する必要があります。ワークフローがなければ、再びASP.NETまたはASP.NET MVCを検討します。

3）会社は、フルタイムの開発者を少なくとも1人、SharePointに捧げなければなりません。開発者の1/2または1/3ではありません。 SharePoint開発を正しく行うには、コミットメントとフォーカスが必要です。あなたはクールエイドを飲む必要があります。 SharePointを専門とするつもりはないが、だまされるつもりならば、その結果のソリューションはひどい（IMHO）。 2人の開発者やチームを捧げることができればさらに優れています（サポート性/保守性/専門性/専門性を考えてください）。

あなたはどう思いますか？

メモ：自分のコラボレーションアーキテクチャの一部としてExchangeとのペアリングを選択した場合、Microsoftのすべてのショップは、SharePointのすぐ使える機能を使用する必要があります。私は反SharePointではない。

UPDATE
SPのワークショップに座った後、私は、SharePointワークフローは、SharePointあたりのリストの項目ごとにのみ適用可能であることを学びました。したがって、ワークフローでSharePointリストアイテムを使用しない場合は、おそらく.NET Workflowの基礎やカスタムを参照する必要があります。これを＃2のアイテムに置き換えてください。

Answer 1

私は同意します。現在のSharepoint（moss 2007/wss 3.0）は、カスタム開発者を非常に辛くて遅いプロセスにしています。私が同意しない唯一のポイントは、ワークフローの部分です。私の考えでは、SharePointのワークフローはほとんど使えないので、避けるべきです。ワークフローを行う場合は、k2：blackpearlまたはMassTransitのオープンソース無料オプションを利用してください。

Answer 2

たとえば、会社の多くのポイントからデータを収集するデータウェアハウスがあるとします。うまくいけば、ビジネス関係者に「ディメンション所有者」と呼ばれるいくつかのディメンションがあります。これらは、ディメンション内のデータの編成に関与する人々です。彼らは階層やリストのようなものを最新に保つ責任がありますが、これらのコレクションには、トランザクションシステムから来る操作データが埋め込まれているわけではなく、ビジネス用語やグループ、およびビジネスで使用される説明です。これは彼らの自然なビジネス言語です。スモールビジネス、ハイリスク、印刷広告のプロモーション25などが挙げられます。データウェアハウスは99％の操作/トランザクション性のものから構築されていますが、それはあなたのユーザーにとって賢明なビジネスアレンジメントです。それを捕まえる場所。

あなたは確かにウェブアプリを作ることができます。 Excelファイルを使用できます。なんでも。しかし、SharePointリストを使用することもできます。 SharePointが魅力的なのは、環境が既に存在している（サポートされている）ということです。要件が広範でない、つまり参照整合性が不要な場合、新しいWebアプリケーションを作成するリソース、ビジネスユーザー

ここでは、SharePointにインストールするコードの作成とライブラリのコンパイルについては言及していません。私はちょうどそれが使用されるために合理的な「正しい時間と場所」を提示しようとしています。

BTW - これは非常に便利ですhow-to on pushing and pulling data between SharePoint lists and SSISです。

Answer 3

SharePointは、ビジネスユーザーのコラボレーション（互いのドキュメントの格納、検索、編集）の基盤として使用する必要があります。 SharePointをアプリケーション開発のためだけに使用すると、問題のポイント3が必要になります。

アプリケーションの開発では、ユーザーをアプリケーションに指し示すWebポータルとしてSharePointを使用したり、Webインターフェイス（ユーザーコントロール、Webパーツなど）をホストすることをお勧めします。ポータル）。

Answer 4

ドキュメントがなくても、カスタムWebパーツを持つポータルのプラットフォームとしてSharepointを使用できます（その一部はサイトのドキュメントライブラリに基づいている可能性があります）。これは優れたポータルプラットフォームであり、私の企業の調査ポータルはシェアポイントベースであり、かなりうまく機能します。良いことは、これらのwebpartsベースのSharePointポータルでは、比較的簡単に権限の問題やプレゼンテーションのカスタマイズの問題（ユーザーが多いbtwなど特定のゾーンなどにwebpartをドラッグする）を処理できることです。また、WSRPタイプのwebpartsはSharepointでもうまく機能します。

あなたは良いSharepointデベロッパーがいる場合にのみ、それはあなたにとって使いやすいものであり、まともなプラットフォーム、ドキュメント、またはドキュメントではありません。