7

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

  1. アプリケーションは、CRM、バグトラッカー、在庫管理、財務管理などのさまざまなモジュールのスイートになります。

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

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

モジュールごとに個別の DLL を用意したいので、スイート全体を制御する単一の DLL をデプロイするときにアプリケーションが壊れる心配はありません。

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

MVC ではなく、ASP.NET Web フォームです。開発にはVS2010を使用します。

これを行うための最良のアプローチは何ですか?

編集：

外部コンテナーという用語は、さまざまなモジュールへのリンクを持つマスター ページのように機能し、さまざまなモジュールが常に同じプロジェクトにあるとは限らないことを意味します。それらは、同じソリューションの下で別のプロジェクトにすることができます。そして、その日の終わりまでに、そのプロジェクトのみを公開し、さまざまなモジュールをそれにもたらすという印象を受けています。

4

4 に答える 4

3

実際、最善のアプローチは、過度に設計しないものだと思います。十分な理由もなく全体的なアーキテクチャを作成しているように見えることを懸念しています。

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

次に2つ目を書きます。最初のモジュールで既に書いたものを使いたくなるでしょう。偉大な。そのためのリファクタリングです。これらを 1 つ以上の「ライブラリ」プロジェクトにリファクタリングし、すべての単体テストを再実行してから、2 番目のモジュールに進みます。

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

このプロセスの最後に、概説した種類のアーキテクチャが必要な場合は、それを手に入れることができます。必要なものが少なければ少なくなり、実際の要件に結び付けられていないアーキテクチャの作成に時間を費やしていないことになります。

于 2010-11-19T17:18:49.470 に答える
2

これが「最善のアプローチ」であるとは言いませんが、アイデアを得るためにDot Net Nuke (DNN) を調べることをお勧めします。これは、Microsoft が ASP.NET プロジェクトを示すために配布した古い "I Buy Spy" スターター Web プロジェクトとして始まり、そこから始まりました。

編集：

1.アプリケーションは、CRM、バグトラッカー、在庫管理、財務管理などのさまざまなモジュールのスイートになります。

これは DNN で行うことができます。DNN や Drupal では「モジュール」とも呼ばれます。

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

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

私たちは、有料の「ソリューションとしてのサービス」アプリケーションをホストするために使用される重要な Web サイトを持っています (アクチュアリーまたは会計士でない場合は、聞いたことがないでしょう)。過去数年間、主任開発者は DotNetNuke の以前のバージョンを、変更が許可されたアプリケーションの部分をリファクタリングする方法のモデルとして使用していました。

于 2010-11-19T16:42:01.050 に答える
1

あなたの会社/製品にちなんでメインプロジェクトに名前を付け、短くシンプルにしてください。それをサポートするには、おそらく1つまたは2つのライブラリプロジェクトが必要になります。これらには、エラーレポート、Webユーティリティメソッドなどの日常的な共通ロジックが含まれます。

次に、目的のサブプロジェクトの1つを選択し（この特定のコンテキストではモジュールという用語は好きではありません）、それをソリューションに追加します。既存のプロジェクトを再利用する場合でも、できればゼロから始める場合でも、最終的には、このプロジェクトの共通ロジックをライブラリに移動することになります。

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

次の記事はMSDNで「古い」とマークされていますが、それでも確認する必要があると思います。

ソリューションとプロジェクトの構造化

また、Patterns and Practices Groupからの類似のもの：

TeamFoundationソース管理におけるプロジェクトとソリューションの構造化

于 2010-11-20T16:58:31.420 に答える
1

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

于 2010-11-20T13:58:19.003 に答える