3

現在、別の言語で記述された複数（約15〜30）の独立したWebアプリケーションがあります。それぞれがファイル、画像、ヘッダー、ユーザー、データベースなどで完全に独立しています。すべてが同じドメインの下に存在し、同じスタイルである必要があることを除いて、9ヤード全体です（ただし、そうではありません）。これらはまもなくC＃ASP.NET MVC 2に変換されます。これらは、同じLDAP認証を共有します。

これらを複数のMVCソリューションとしてセットアップする必要があるのか​​、単一のMVCアプリケーション内で実行するのかという疑問が浮かびました。それらはすべて同じスタイル、ほとんど同じ画像を持ち、基本的な機能を共有するのがいいでしょう。

これが私にとって単純なカットアンドドライソリューションではない理由は、これらのアプリケーションのいくつかはそれ自体で非常に大きく、それらをすべて一緒に投げることは管理が難しいかもしれないからです。言うまでもなく、新しいアプリケーションの開発は継続され、既存のアプリケーションに新しい機能が追加されます。これをおそらく非常に大きな解決策にします。

私はMVCにかなり慣れていないので、今ではよく理解していますが、方法論と設計を操作するために、あちこちで脳を再配線しようとしています。

私が求めているのは、MVCの実際の使用に関するいくつかの刺激と知恵を共有して、私が考え始める方向を与えるために、私よりもMVCの経験が豊富な皆さんです。

4

6 に答える 6

3

複数の Web アプリケーションを 1 つのアプリケーションにまとめる場合は、次の点を考慮します。

  • すべてのアプリケーションが共通のビジネス モデルを共有している場合。
  • 共通のインフラストラクチャ (セキュリティ、検証、ロギングなど) を共有している場合
  • 彼らが同じ共通のユーザーベースを共有している場合。
  • 複数のプロジェクトを 1 つにまとめることで、メンテナンスと機能強化のコストを削減できる場合。

あなたの場合、それぞれが完全に独立していると言いましたが、なぜ結合する必要があるのですか?

于 2012-06-11T10:21:21.823 に答える
3

1 つのソリューションにそれらを組み合わせないでください。私はかつて、1 つの巨大な解決策があり、それがすべての悪の根源であるプロジェクトで働いていました。すべてを単一のソリューションに配置すると、すべてのプロジェクトの複雑さが増します。何かを再利用することで、実際には数行のコードを節約しようと考えているかもしれませんが、実際には、致命的なソリューションを作成していることになります。最終的にボトルネックになる

次の点を考慮してください。

  • プロジェクト数が 30 ～ 40 を超えると、Visual Studio のパフォーマンスが影響を受けます。つまり、ビルドにかかる時間がますます長くなります。

  • ビルド サーバーを実装する場合 (実装する必要があります)、1 つの巨大なソリューションがある場合、各アプリケーションに関連するプロジェクトのみをビルドするスクリプトは非常に複雑になります。

あなたが言うとき、あなたはすでに設計の最も難しい部分をやったと思います：

現在、別の言語で書かれた複数 (約 15 ～ 30) の独立したWeb アプリケーションがあります。

アプリケーションが独立している場合、それは独立したドメインを持っていることを意味するため、それらを単一のソリューションに配置する理由はなく、モジュールとして扱うことさえありません。

独立したソリューションを管理することは、それらの間でコンポーネントを共有できないという意味ではありません(ところで、共有コンポーネントと言うときは、インフラストラクチャ コンポーネントを意味します。ドメイン オブジェクトを再利用しようとしないでください)。

では、問題は、共有コンポーネントをどのように参照すればよいかということです。

最近、ソリューション プロジェクト間でインフラストラクチャ コンポーネントを再利用する最善の方法はNugetsを使用することであることがわかりました。Nugets を使用すると、新しいバージョンのコンポーネントを簡単に配布できるので、私の提案は次のとおりです。組織内にプライベート Nuget サーバー (単純な IIS アプリケーション) を作成し、このサーバーに独自のプライベート パッケージを追加して、ソリューションからそれらを参照するだけです。

Nuget パッケージには、次のような必要なものを実質的に配置できます。

  • アセンブリ
  • XML 構成ファイル (一般的な XML ロガー構成ファイルを含む)
  • 一般的な JavaScript ファイル
  • 共通スタイル シート ファイル
  • 等...

これは、プライベート Nuget リポジトリを作成するための良い記事です。

Nuget を作成するには:

最後に、Nuget の作成を CI サーバーに統合します。

于 2012-06-12T20:17:02.223 に答える
2

私の推奨事項はDIであり、プラグインのように各プロジェクトを作成します。これにより、各プロジェクトを他のプロジェクトに影響を与えることなく個別に開発または管理できます。

MEFにはいくつかのプロジェクトがあり、新しいプラグインを作成したり、既存のプラグインを管理したりするのはとても簡単です。

MVCとMEFの概要は次のとおりです… http：//blog.maartenballiauw.be/post/2009/04/21/ASPNET-MVC-and-the-Managed-Extensibility-Framework-%28MEF%29.aspx

およびダウンロード可能な例http://www.hanselman.com/blog/ExtendingNerdDinnerAddingMEFAndPluginsToASPNETMVC.aspx

于 2012-06-08T18:06:51.490 に答える
2

アプリ内のページで同様のマークアップを使用する限り、すべてが参照する統一されたスタイルシートで同じスタイルを実現できます。共通の機能は、統一されたクラス ライブラリを通じて提供できます。私にとっては、スタイルと機能がアプリ間でどれだけ近いかによって異なります...すべてのページでまったく同じマークアップが必要ですか、など.

于 2012-06-11T19:36:03.373 に答える
1

アプリケーションごとにコントローラーのインスタンスを持つのが一般的ですが、データ駆動型のフロント コントローラーを使用してこれを実装する場合、新しい Web アプリケーション フレームワーク内に必要なクラスは 1 つだけです。そのため、各アプリケーションには、URL をコマンドクラス ファイルにマップする構成ファイルが含まれる場合があります。これらはオンデマンドで構築することも、リソース プールから要求することもできます。このアプローチの大きな利点は、これらのコマンドの多くが、既存のアプリケーションや ASP ビューに対する非常に薄いラッパー ( ServiceToWorker ) として開始されることです。

于 2012-06-11T11:58:28.243 に答える
1

私はMarksの答えに完全に同意します。「なぜ」それらを組み合わせる必要があるのか​​ 自問してください。彼らは本当に独立する必要がありますか？

私の追加のコメントは....

絶対に考えるべきことは……。

  1. アプリケーションで使用するのと同じ画像を使用する統合 CSS ファイルを作成します

  2. JQuery テンプレート/部分ビューを使用してユニバーサル JQuery (公開されている場合はモバイル バージョン) を記述して、これらすべての個別のアプリケーションに統一されたエクスペリエンスを提供します。

DAL などに関してサーバー側のコードを統一する予定がない場合は、クライアント側に集中してください。

于 2012-06-11T20:13:49.217 に答える