モジュール式の整ったASP.NETアプリケーションを設計するための最善のアプローチ

Question

私は、製品開発のためのWebアプリケーション開発フレームワークについて考えています。私はそれに多くのサブモジュールを持つASP.NETアプリケーションを構築したいと思います。私の要件は次のようにしている：

1. 、独自のDLLを持っていなければならないアプリケーションは、各モジュール等のCRM、バグトラッカーのような異なるモジュールのスイート、在庫管理、財務管理

2. になります。

3. 1つのプロジェクトは、フレームワークのようなアプリケーションの外部コンテナ用である必要があります。このプロジェクトは、ソリューション内の他のすべてのモジュールを外部コンテナに持ち込む必要があります。 （HTMLにはフレームがあるようなものもあります）。したがって、我々は一日の終わりにのみ外部コンテナWebアプリケーションを公開し、それを介して他のすべてのWebアプリケーションプロジェクトにアクセスします。

私はスイート全体を制御し、私の単一のDLLを展開していたアプリケーションの破壊について、恐れる必要はありませんので、モジュールごとに個別のDLLを持っていると思います。

私の考えが正しい方向にあるかどうかはわかりません。私が探している最終的な結果は、よく管理され、整理され、モジュール化されたWebアプリケーションスイートです。

これはASP.NET Webフォームであり、MVCではありません。私は開発のためにVS2010を使用します。

これを行うにはどのような方法が最適ですか？

編集：

用語外部コンテナは、それが様々なモジュールと各種モジュールへのリンクは、同じプロジェクトに常にではありません持っているマスターページのように働くことを意味します。それらは同じソリューションの下で別々のプロジェクトにすることができます。そして、私はその日の終わりまでに、私はそのプロジェクトだけを公開し、さまざまなモジュールをそのプロジェクトに公開するという印象を受けています。

Answer 1

これは「最善のアプローチ」とは言いませんが、私はDot Net Nuke（DNN）を見ていくつかのアイデアを得ることをお勧めします。これは、MicrosoftがASP.NETプロジェクトを表示するために配布した古い「I Buy Spy」のスターターWebプロジェクトとして開始され、そこから飛び出しました。

編集：

1.アプリケーションは、あなたがDNNでこれを行うことができCRM、バグトラッカーのような異なるモジュールのスイート、在庫管理、財務管理など

になります。 DNNとDrupalでは「モジュール」とも呼ばれています。

2.各モジュールには独自のDLLが必要です。

はい、これは良い考えです。 DNNやDrupalのようないくつかのコンテンツ管理システムでは、このようなことが起こります。この方法では、同じWebサイトのすべての実装ですべてのモジュールをインストールする必要はありません。

私たちは、私たちが請求する（サービスや会計士でなければあなたがそれを聞いたことがない） "ソリューションとしてのサービス"アプリケーションをホストするために使用される重要なウェブサイトを持っています。過去数年間のリード開発者は、アプリケーションの変更部分をどのようにリファクタリングするかのモデルとして、DotNetNukeの以前のバージョンを使用しました。

Answer 2

私が実際に考えているのは、オーバーアーキテクトではない最良のアプローチだと思います。十分な理由なしに全体的なアーキテクチャーを生み出しているようです。

これらのモジュールはすべて新しくなっていますか？その後、最初の文字を書き始めるだけです。単一のモジュールに適用されるベストプラクティスを使用してください。

次に、もう1つを書きます。最初のモジュールですでに書いたことを使いたいと思うでしょう。すばらしいです。これがリファクタリングの目的です。これらの要素を1つ以上の "ライブラリ"プロジェクトにリファクタリングし、すべての単体テストを再実行してから、2つ目のモジュールに進みます。

すべてのモジュールが完了するまで繰り返す。

このプロセスの最後に、あなたが概説したアーキテクチャの種類が必要な場合は、それを使用します。必要なものが少なくて済むと、必要なリソースが少なくなり、実世界の要件に縛られていないアーキテクチャを作成する時間を費やすことはありません。

Answer 3

他の人の意見によると、DNNはおそらくあなたがやろうとしていることに役立つでしょう。自然に自分自身を完全にロールしたいのであれば、コンテナ「フレームワーク」とユーザーコントロール（.ascx）を組み合わせたものに変わります。コンテナは、メニュー付きのマスターページと同じくらい単純なものにすることができます。デザインの柔軟性に応じて、それぞれ異なるコントロールをホストする多数の異なるページを事前に作成できます（必要に応じて別々のdllを使用できます）。もう少し動的にしたい場合は、実行時に目的のユーザーコントロールを動的にロードする1つのコンテンツページを持つことができます。ここでもこれは単なる一般的なアプローチであり、とにかくDNNがどのように実装されているかについての30000フィートの見解です。

Answer 4

あなたの会社/製品の後ろのメインプロジェクトに名前を付けて、それを簡潔にしてください。おそらく、それをサポートするために1つまたは2つのライブラリのプロジェクトが必要になります - これらは、error reporting、ウェブユーティリティメソッドなど

次のようなもののために毎日の、一般的なロジックを含むのいずれかを選択しますあなたの意図sub-projects（私は好きではありませんこの特定のコンテキストではモジュールという用語を使用します）、それをソリューションに追加します。既存のプロジェクトを再利用している場合でも、好ましくはゼロから始める場合でも、最終的にはこのプロジェクトの共通ロジックがライブラリに移動されます。

リンスして繰り返します。おそらくCMS、ブログ、カレンダー、フォーラムなどのいくつかのサブプロジェクトを含むSueetieプロジェクトのようなものを見てください。

次の記事はMSDNで "時代遅れ"とマークされていますが、それを見て：

また

Structuring Solutions and Projects

、パターンとプラクティスグループから似たような：

Structuring Projects and Solutions in Team Foundation Source Control