私たちの組織は、約2年前にSharePointパスを開始しました。その前に、私たち（開発者）は主にSQLバックエンド用のasp.netフロントエンドを作成しました。これで、新しいプロジェクトが登場するたびに、SharePointに「適合させる」ように求められているようです。また、SharePointには、複雑さと他のテクノロジとの相互作用のために、スタンドアロンアプリケーションまたはWebアプリケーションであるはずのいくつかのものを詰め込みました。
私の質問は次のとおりです。SharePointとWeb/Winformアプリケーションでプロジェクトを開発することについて、どこに線を引きますか。また、SharePointが特定のプロジェクトに最適なソリューションではない可能性があることをマネージャーにどのように納得させますか。
これは時々難しい質問だというあなたの意見に同意します。ただし、一般的には、sharepoint アプリについて少し違った考え方をする必要があるという決まり文句には同意します。データがリストベースであると見なせる場合、SharePoint は必ずしも悪い開発フレームワークではありません。表面的にはより多くの作業のように見えるかもしれませんが、IMO の課題はある場所から別の場所に移動するだけです。カスタム フィールド テンプレートや Web パーツなどを使用すると、あらゆる種類のデータを比較的自然に処理できます。また、SharePoint の優れた側面を無料で利用できます (既に成熟したセキュリティ フレームワーク、組み込みの検索機能、サイトとリストのテンプレート/定義、パーソナライズされたページのカスタマイズ、yada、yada)。
また、ここでの「複雑さと他のテクノロジとの相互作用」が何を意味するのかわからないため、SharePoint がミックスに追加されたときにどのような特定の問題が発生するかを想像するのは困難です.
あなたの開発チームが比較的 SharePoint の経験がなく、品質と期限を気にしているのであれば、あなたの言いたいことは間違いなくわかります。簡単に習得できるものではありませんが、SharePoint 製品は、多くの人が評価しているよりも自然に拡張可能であると思います。
場合によっては、SharePoint アプリケーションと ASP.NET アプリケーションの間に 3 番目のオプションがあります。カスタム サイトとアプリケーション ページを作成して、それらを SharePoint サイトに展開できます。これにより、SharePoint 環境内で ASP.Net と SQL Server を使用できるようになります (つまり、SharePoint のセキュリティなども活用できます)。単純な ASP.Net アプリケーションを開発するほど簡単ではありませんが、妥協は必要です。
もちろん、これらの新しいアプリケーションを単に SharePoint の "内部" ではなく、SharePoint テクノロジ (リスト、ライブラリ、ワークフローなど) 上に構築することを望んでいる場合、これは一種の技術的な問題です。
SP にアプリケーションを配置する主な理由の 1 つは、SP が提供するビルディング ブロックを利用したい場合です。
新しいアプリを既存のプールに「統合」しようとする際に考慮すべきことの 1 つは、合併の恩恵を受けるデータ (顧客、在庫など) に重複があるかどうかです。
複数のアプリケーションとそれぞれのデータをすべて 1 か所にバックアップできるという利点もあります。
すべてを SharePoint に移行するよう求めているのはなぜですか?
私の経験では、以前の SharePoint イントラネットが、すべてをまとめて 1 つの情報アーキテクチャの下で見つけられるようにするためのポータルとして優れているためです。
組織内のアプリケーション スペースに対するユーザーの認識から問題にアプローチします。
アプリケーションがイントラネット サイトの一部のように見え、ユーザーがそこにアクセスする方法 (および戻る方法) を考える必要がない限り、アプリケーションを取得するために必要なアーキテクチャの決定をほとんど行うことができます。実装と保守に関しては、組織にとって最高の価値があります。
サイトについて、SharePoint とその他のことから、情報アーキテクチャ、検索可能性、および使いやすさの優れたウーリー コンセプトまで考え始めたとき、実際には SharePoint 内に作成しないことを決定しましたが、それでもイントラネットのように皮をむき、販売が容易になりました。