3

多くのインターフェースといくつかの基本的なデフォルト実装を定義するフレームワークがあります。これを CompanyFramework と呼びましょう。現在、別のプロジェクト CompanyFramework.Web.Mvc に格納されている ASP.NET MVC 拡張機能がいくつかあります。これは、コア フレームワークを使用するが MVC とは関係のないアプリケーションが ASP.NET MVC ライブラリを参照する必要がないようにするためです。余分なアセンブリには 3 ～ 4 個のクラス ファイルしか含まれていないため、このセットアップはあまり好きではありませんが、メイン フレームワーク アセンブリに不要な依存関係を導入することを避ける最もクリーンな方法でした。

現在、ASP.NET MVC に使用する StructureMap 固有の拡張機能がいくつかあります。具体的には、カスタム コントローラー ファクトリとモデル バインダー タイプのものです。そのようなものをどこに置きますか？CompanyFramework.Web.Mvc プロジェクトでそれをスローすることもできますが、それを使用する ASP.NET MVC プロジェクトは、使用されていなくても、StructureMap アセンブリへの参照を持つことになります。別の CompanyFramework.StructureMap プロジェクトを作成することもできますが、ASP.NET MVC に依存しない StructureMap の拡張機能を開発したとしても、MVC アセンブリを使用するクラスの MVC アセンブリを参照するのは面倒です。

別の CompanyFramework.Web.Mvc.StructureMap プロジェクトを作成する必要がありますか? このアプローチは全体的に最もクリーンに見えますが、プロジェクト全体の構造を乱雑にする軽量のサテライト アセンブリを導入し始めているように感じます。

4

3 に答える 3

2

さらに悪いことに、依存関係が悪い、またはいくつかの余分なプロジェクトがありますか？少し雑然としたIDEは、明確に定義された構造に支払うための小さな代償です。

于 2011-05-13T18:50:19.380 に答える
1

このような質問については、将来の変更に関する決定の長期的な影響を考慮することが役立つと思います. 最終的に、これらのライブラリの一部は廃止されて置き換えられますが、他のライブラリは存続します。たとえば、MVC に取って代わるいくつかのテクノロジが登場します。

これらを別々に保つことで、将来の開発者やメンテナーの生活がずっと楽になると私は信じています。依存関係がより明確になり (これは常に良いことです)、移行の決定はより自信を持って明確に行うことができます。

また、拡大を続ける Big Ball of Mud ライブラリは、他の多くの理由から、今後すべてのプロジェクトに追加する必要はありません。「軽量アセンブリの束」は、優れた設計目標のように思えます。

于 2011-05-13T19:02:04.840 に答える
0

StructureMap を MVC プロジェクトに配置することをお勧めします。これは論理的に最も理にかなっており、場合によっては未使用の参照を持っていても問題はないと思います。

現在のセットアップ (CompanyFramework アセンブリ + MVC アセンブリ) はかなり合理的だと思います。共通アセンブリ、Web アセンブリ (または特に MVC または Web フォームを対象としたもの)、データベース アセンブリなど、同じ種類のパターンに従うことになることがわかりました。このように高機能レベルでそれらを分離することは、開始するには良い場所です。

于 2011-05-13T19:07:23.897 に答える