7

これらの条件下でのアプリケーション開発にのみ SharePoint を使用する必要があるという見解があります。

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 人の開発者または 1 つのチーム (サポート/メンテナンス/専門知識/専門性を考えてください) を専任できればさらに良いでしょう。

それで、あなたはどう思いますか？

注: Microsoft のすべてのショップは、コラボレーション アーキテクチャの一部として SharePoint と Exchange を組み合わせることを選択した場合、SharePoint のすぐに使える機能を使用する必要があると思います。私はアンチ SharePoint ではありません。

更新
SP ワークショップに参加した後、SharePoint ワークフローは SharePoint リスト アイテム単位でしか適用できないことを知りました。したがって、ワークフローで SharePoint リスト アイテムを使用しない場合は、おそらく .NET ワークフローの基盤または何かカスタムを検討する必要があります。これを私の＃2アイテムの代替品と考えてください.

4

4 に答える 4

5

私は同意します。Sharepoint は現在 (moss 2007/wss 3.0)、カスタム開発を非常に苦痛で遅いプロセスにしています。私が同意しない唯一の点は、ワークフローの部分です。私の意見では、SharePoint のワークフローはほとんど使用できず、避けるべきです。ワークフローを実行する場合は、k2:blackpearl または MassTransit でオープン ソースの無料オプションを選択してください。

于 2009-07-24T14:22:53.273 に答える
3

社内のさまざまな場所からデータを収集するデータ ウェアハウスがあるとします。ビジネス関係者が「ディメンション オーナー」として指定されているディメンションがいくつかあることを願っています。これらは、ディメンション内のデータの編成に関与している人々です。階層やリストなどを最新の状態に保つ責任がありますが、これらのコレクションには、トランザクション システムから取得した運用データが取り込まれていません。ビジネス用語やグループ、ビジネスが話す説明です。これは彼らの自然なビジネス言語です。East Sales Team、Small Business、High Risk、Print-Ad Promotion 25 など。要点は、データ ウェアハウスが 99% の運用/トランザクション要素から構築されているということですが、ユーザーにとってすべてを合理的にするのはビジネスの取り決めであり、捉える場所。

確かにWebアプリは作れます。エクセルファイルが使えます。なんでもいい。ただし、SharePoint リストを使用することもできます。この点で SharePoint が魅力的なのは、環境が既に存在している (したがってサポートされている) 場合、要件が広範でない場合 (参照整合性が不要な場合)、新しい Web アプリを作成するためのリソースがない場合、ビジネス ユーザーです。すでに SharePoint に慣れていて快適である、昨日必要になった、など。

そのため、ここでは、SharePoint にインストールするコードの記述とライブラリのコンパイルについて話しているわけではありません。私は、それが使用される合理的な「適切な時間と場所」を提示しようとしているだけです.

ところで - SharePoint リストと SSIS の間でデータをプッシュおよびプルするための非常に便利なハウツーを次に示します。

于 2009-07-24T15:21:31.430 に答える
1

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

アプリケーション開発の場合、SharePoint を Web ポータルとして使用して、ユーザーをアプリケーションに誘導したり、(ユーザー コントロール、Web パーツなどを介して) その Web インターフェイスをホストしたりすることを好みます (ああ、待って、SharePoint は Web ポータルであると言いました)。

于 2009-07-26T07:30:59.213 に答える
0

ドキュメントがなくても、Sharepoint をカスタム Web パーツ (サイトのドキュメント ライブラリに基づいている場合があります) を備えたポータルのプラットフォームとして使用できます。これは優れたポータル プラットフォームであり、私の会社のリサーチ ポータルは SharePoint ベースであり、非常にうまく機能します。良い点は、これらの Web パーツ ベースの SharePoint ポータルを使用すると、アクセス許可の問題やプレゼンテーションのカスタマイズの問題 (Web パーツを特定のゾーンにドラッグするなど、ユーザーがよく行うこと) を比較的簡単に処理できることです。また、WSRPタイプの Web パーツは、Sharepoint とうまく連携します。

確かに、優れた Sharepoint 開発者がいる場合にのみ、それはあなたにとって物事を簡単にし、まともなプラットフォーム、ドキュメント、またはドキュメントがない場合に限ります。

于 2009-09-01T15:31:22.750 に答える