大規模なアプリケーションを開発する正しい方法

Question

.Net 3.5で非常に大きなWebアプリケーションを開発しています。異なる分野の専門知識を持つ2つの独立したベンダーが関与しています。両方のベンダーはリモートにあり、同じWebアプリケーションの別々の機能領域で作業しています。 UIの開発を処理する最良の方法は何だろうと思っていました。

UIのマスター構造には、左側と上部にナビゲーションリンクがあります。リンクをクリックすると、メイン領域にページが開きます。個々のページは各ベンダーによって開発されます。マスター全体を1つのベンダーで開発できます。マスターレイアウトでは、iframeを使用してメインエリアに個々のページを表示します。

IIS-Masterのプールにマスターアプリを展開し、IIS-AのプールにベンダーAアプリを展開し、IIS-BのプールにベンダーBアプリを展開します。ユーザー数が多い場合に負荷分散を行うIISのプール。

また、このWebアプリケーションはアクセスベースです。つまり、ユーザーはページにアクセスするためにログインする必要があります。ここではさまざまなサイトが関係しているため、シングルサインオンを実装する必要があることを理解しています。

これは良い考えですか？代替手段はありますか？

---

返信後に編集

私もあなたの返信で述べたのと同じ不安を持っています。しかし、私が念頭に置いている解決策は、2つのベンダーが関与しているというだけではありません。 2つのベンダーが関係しているのは、2つの別個の機能領域があり、両方の領域に独自のユーザー負荷があるため、負荷分散も適切に行われるためです。シングルサインオンを実装した2つのサイトを完全に作成することを考えていました。しかし、問題はUIの共通部分のメンテナンスです。共通ライブラリは、あるベンダーによって開発され、他のベンダーにDLLを配布できるため、簡単です。 UIレイヤーに対してこれを行うにはどうすればよいですか？

Answer 1

分散したチームとの連携は、特に大規模なアプリケーションでは困難な場合があります。実際、開発ライフサイクルが容易になると考えているため、アーキテクチャを不必要に変更する場合があります。

個人的には、バージョン管理、継続的インテグレーション、コードレビュー、オープンなコミュニケーションなどのソフトウェアの基礎は非常に優れていると考えています。このプロジェクトを、たまたま複数の開発チームによってコーディングされた単一のアプリケーションと考えることをお勧めします。コード統合を担当する人を作成し、すべてのチームが同じページにいることを確認し、チームのダイナミクスに合わせてアーキテクチャを変更しないでください。

質問しなければならないのは、複数のサイトとシングルサインオンシステムを不必要に維持する方が本当に良いのか、それとも単にベンダーを隔離し、そのコア領域に焦点を合わせ続けるためにこのアプローチを提案するだけなのかアプリケーションは正しいアプローチですか？

Answer 2

あなたが書いたことに対する私の第一印象は、アーキテクチャを再考する価値があるかもしれないということです。

iframeを使用すると、多くの問題が発生します。最初の問題は、ブラウザの[戻る]ボタンの動作です。

可能な代替方法は、マスターアプリケーションとAおよびBの間でリモート処理またはWebサービスを使用し、ユーザーインターフェイス全体を1か所で処理することです。一貫したUIの開発を2つの異なるベンダーと調整することは非常に難しい場合があります。

Answer 3

ソース管理ブランチの同じインスタンスを共有している限り、両方の開発者が同じUIプロジェクトで作業できないのはなぜですか。マスターページが開発されると、両者はマスターテンプレートに対してクライアントページを構築できます。相手にバグを起こすことはありませんか？