4

私たちの会社のために、一連のサブアプリケーションを備えた大きなエクストラネット Web サイトを作成しています。ソリューションとプロジェクトの正しいセットアップがどうあるべきか、少し戸惑っています。

ポータルと呼ばれる 1 つの Web アプリケーションがあります。これには、認証/承認クラス、マスターページ、ナビゲーション/URL ルーティング クラス、およびテーマ定義が含まれています。また、お客様がプロジェクトのステータスをすばやく把握できるように、いくつかの基本的な概要も含まれます。

来年には、より多くのアプリケーションを開発し、ポータルと統合する予定です。機能 A、B、C と呼ばれる詳細な概要とツールと考えてください。何年にもわたって、これらのアプリケーションを改善し、新しいバージョンをリリースします。これらの Web アプリケーションは、ポータルのナビゲーションにシームレスに適合する必要があります。マスターページとテーマを再利用してほしいです。

このソリューションをセットアップする適切な方法は何ですか?
アプリケーションを結び付け、マスター ページを再利用し、維持できるようにするにはどうすればよいでしょうか?
特定の Web コントロール (ASCX) を適切な方法で共有するにはどうすればよいですか?
私たちはTFSを使用していますが、おそらく分岐/マージのアイデアはありますか?

編集:
ASP.Net WebForms で作成したいのですが、その分野で最も経験があります。しかし、基本的には何でも使用できます。Web サーバーは独自の制御下にあります (Microsoft 指向である限り、php などに切り替える必要はありません :))

4

7 に答える 7

2

What is the proper way to setup this solution?

正しい方法は…たくさんあります。私は多くのアプリケーションと多くの異なるセットアップを見てきました (その多くは「適切」と見なされます)。あなたが本当に求めているのは、あなたの状況に最適な方法です。

ポータルを構築しているため、アプリケーションの追加機能を開発する際に役立つ、機能を分離する贅沢が得られます。

機能ごとに個別のフォルダーを使用して、1 つの Web サイトをセットアップします。単一の Web サイトにすることで、特別なことをしなくても、すべての機能が同じマスターページ、ユーザー コントロール、および構成ファイルを共有できるようになります。（その点については、すべてのマスターページをフォルダーに入れ、ユーザーコントロール用に別のフォルダーを作成します）。

How can I tie the applications together, re-use the master pages and keep it maintainable?

ここでも...フォルダーが最適なオプションです。フォルダーは各機能を分離するのに役立ち、アプリケーションを管理しやすくします。

How can I share certain webcontrols (ASCX) in a proper way?

まず、ascx ファイルは Web コントロールではありません。それらはユーザーコントロールです。WebControl は、別のアセンブリに存在するサーバー コントロールを作成するためのクラスです。上で述べたように、ユーザー コントロールに関しては、別のフォルダーに配置すると、常に 1 つの場所にあり、アプリケーション全体で使用できます。

We are using TFS, perhaps any branching/merging ideas?

ここでは、特に何もする必要はありません。分岐に関しては、さまざまな方法があります。

  • 1 つは、リリースごとにブランチを作成することです。
  • もう 1 つは、追加する新機能ごとにブランチを作成することです (あなたの場合、これは最初のオプションとほぼ同じです)。
  • さらに別の方法として、開発者ごとにブランチを作成する方法があります。

コードをどのように分岐するかを決めるとき、何が自分を最も保護してくれるかを考えます。あなたの場合、機能リリースの間にバグ修正を計画する必要があるため、リリースごとに 1 つのブランチが最も理にかなっています (開発ブランチと呼びます)。ただし、機能が分離されているため、1 つの機能がアプリケーションの残りの部分に影響を与えない場合があります。安全のために、この種の分岐は必要ないかもしれません。

于 2010-02-05T01:04:12.733 に答える
2

Brian が言うように、API を公開するときは、できる限りコミットする必要があります。つまり、最初のリリース後はできるだけ変更しないようにする必要があります。ただし、安定したものを作成するには、前もって多くの努力が必要です。そのため、API にコミットする準備ができていない場合は、代わりに可能な限り内部化する必要があります。そのため、物事を分離するよりも結合する必要がある場合があります。

ただし、5 段落の説明に基づいてアプリケーションに適合するアーキテクチャを提案するつもりはありません。あなたがする必要があるのは、いくつかの大きなプロジェクトを持つことと、疎結合された小さなプロジェクトをたくさん持つことの長所と短所を比較検討することです。つまり、前もって計画を立てるほど、計画に固執すれば、計画を立てるのが簡単になります。

したがって、Brians の回答とは逆に、システム全体を「できるだけ疎結合」にすることはお勧めしません。必要なだけ疎結合にすることだけをお勧めします。;) 疎結合コードを悪用すると、密結合コードと同じくらい多くの問題が発生する可能性があります。

参照:
1.多数の小さなアセンブリと 1 つの大きなアセンブリのどちらが優れていますか?
2.多くの「小さな」アセンブリに固有の欠点は?

最終的には、「...機能」、保守性、拡張性、信頼性などのそれぞれにどれだけ集中したいかを知っているのはあなただけです。したがって、優先順位と目標を明確にし、それに応じて計画してください。

分岐戦略については、 TFS 分岐ガイドライン 2.0を読むことができます。これには、基本的なものから高度なものまで、さまざまな分岐戦略の優れた紹介があります。TFS を使用していない場合でも、これは読むのに適したガイドです (私は現在 SVN を使用しています)。私は現在、1 人から 4 人の開発者の小さなチームで働いているため、基本と標準の間の戦略を使用する傾向があります。これを推奨しているわけではありませんが、私たちのチームにとって最適な方法です。

プロジェクト間でのコードの共有について。SVN では「externals」を使用できます。つまり、共有ファイルが複数のフォルダーに表示されるため、1 つのコピーを変更してその変更を svn にコミットすると、他のすべてのコピーが次の svn 更新で更新されます。ただし、TFS に似たようなものがあるかどうかは思い出せません。

注: SVN の外部変数に注意してください... 問題が発生する可能性があります。;)

私のアドバイスは、できるだけ aspx、ascx、およびマスター ページを共有しないようにすることです。それは通常、それが役立つよりもはるかに痛い. 代わりに、継承または他の代替手段を使用して目標を達成してください。

ASP.NET MVC 2.0 には、「領域」と呼ばれる概念があり、アプリケーションのサブセクションを残りの部分から分離して構築します。私の知る限り、これらの領域は「メイン」アプリケーションとは別のプロジェクトで維持できます。あなたが要求しているものとよく似ているように思えますので、それを調べたほうがいいかもしれません。

それが理にかなっていることを願っています。;)

于 2010-02-03T00:41:34.017 に答える
1

今から MVC の概念を使用します。堅牢なアプリケーションの拡張性と柔軟性が向上します。

于 2010-02-09T11:11:59.730 に答える
1

カスタムVirtualPathProviderの実装を調べると役立つ場合があります。私の最後のプロジェクトでは、テーマ ファイル (マスター ページ、ユーザー コントロール、画像、スタイル シート) を共有する必要がある複数の ASP.NET サイトがあったため、仮想フォルダー (/Themes など) を任意の物理フォルダーにマップできる VirtualPathProvider を作成しました。ハード ドライブのフォルダ (例: C:\Shared\SiteThemes)。

些細なことではありませんが、それほど時間はかからず、問題も発生していません。ちなみに、これは WiX の最大コンポーネント制限を克服するための優れた方法であることが判明しました... VirtualPathProvider を使用するサイトをプリコンパイルできないことに注意してください。

于 2010-02-04T13:23:19.323 に答える
1

システムをできるだけ疎結合にすることを検討します。アプリケーションを追加すると、Web サイトの信頼性が低下します (100% の時間稼働するコンポーネントはないため、これらを組み合わせると全体的な信頼性が低下します)。そのため、主要でないサービスのダウンに対応できるようにシステムを構築する必要があります (たとえば、Amazon のホームページには 100 ほどのサービスが貢献していると思います。そのため、フォールト トレラントになるように構築されています)。

結合を壊さずに実装を変更できるように、サービス間の API は可能な限り安定した状態を維持する必要があります。個々のサービスをテストしても全体的な動作に関するカバレッジはほとんど得られないため、Web レベル (おそらくSeleniumなど)での自動テストも調査する必要があります。

于 2010-01-30T12:21:25.923 に答える
0

SharePointの使用を検討するかもしれません。特にイントラネット環境で共存する場合は、ASP.NETアプリケーション配信に適したプラットフォームです。それはあなたに無料でたくさんのものを与えます。

もちろん、ひじは非常に粗いので、注意して進めてください。

于 2010-02-08T20:43:11.863 に答える
0

私はアプリケーションを個別のものとは考えていませんが、ポータル全体のモジュールと考えています。

これは完全に適合するように思われるので、MEF を調べることをお勧めします。

http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx

于 2010-02-09T20:31:38.777 に答える