11

Onion アーキテクチャは、関心の分離と疎結合を維持するためにアプリケーションを構築する方法です (サンプル プロジェクト: http://onionarch.codeplex.com/ )。依存関係の注入/解決は、すべてのレイヤーを結び付けるために使用されるため、このアーキテクチャの重要な側面です。

上記のリンクには、Onion レイヤーを使用して ASP.NET MVC を構築する方法に関するサンプル アプリケーションが含まれています。私はとても気に入っていますが、これらの例のほとんどは Ninject を使用しています (かなり遅いことは誰もが知っています)。誰かが別の DI ツール (SimpleInjector、Unity、Autofac など) を Onion Project に統合する方法について詳しく説明できるかどうか疑問に思っていました。

すべてのレイヤーが 1 つの依存関係 (MVC プロジェクトを含む)、つまりコア レイヤーのみを持つことが重要です。依存関係解決レイヤーを除いて、このレイヤーはすべてのレイヤーを参照できます。

DI を使用し、MVC レイヤーに DI ツールへの参照を含めずに、MVC プロジェクトをスタートアップ プロジェクトとして設定するのに苦労しています。

4

2 に答える 2

16

あなたの質問は

「別のDIツール（SimpleInjector、Unity、Autofacなど）をOnionプロジェクトに統合するにはどうすればよいですか？」

Ninjectの代わりにStructureMapを使用しています。統合された方法は、他のDIフレームワークでも問題ないはずです。

あなたが言ったように、依存関係解決レイヤーだけが他のすべてのレイヤーを参照する必要があります。それはあなたのオニオンアーキテクチャの最外層です。そうするために、 BootStrapperというプロジェクトを作成しました。これは、StructureMapアセンブリを参照する唯一のプロジェクトです。このプロジェクトのApp_Startフォルダーには、次のようなStructureMapMvc.csという名前のファイルがあります。

[assembly: WebActivator.PreApplicationStartMethod(typeof(XXXX.BootStrapper.App_Start.StructuremapMvc), "Start")]

namespace XXXX.BootStrapper.App_Start
{
    public static class StructuremapMvc
    {
        public static void Start()
        {
            IContainer container = IoC.Initialize();
            System.Web.Mvc.DependencyResolver.SetResolver(new StructureMapDependencyResolver(container));
            GlobalConfiguration.Configuration.DependencyResolver = new StructureMapHttpDependencyResolver(container);
            ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory());
        }
    }
}

興味深い行は次のとおりです。

[assembly: WebActivator.PreApplicationStartMethod(typeof(XXXX.BootStrapper.App_Start.StructuremapMvc), "Start")]

ナゲットパッケージの説明によると：

WebActivatorは、他のパッケージがWebアプリでスタートアップコードを実行できるようにするNuGetパッケージです。

かなりかっこいいですね 最後に配置する必要があるのは、BootStrapperプロジェクトアセンブリがWebアプリケーションの/ binフォルダーにプッシュされることを確認することです（ビルド後のアクションまたはOutputToナゲットパッケージを使用して簡単にセットアップできます）。これにより、MVCプロジェクトでBootStrapperプロジェクトを参照したり、OnionArchitectureの原則に違反したりする必要がなくなります。

したがって、これらすべてが整っていると、コンポジションルートパターンに完全に準拠し、アプリが起動すると、モジュールが一緒にコンポジションされます。

お役に立てれば！

于 2013-03-04T11:01:10.030 に答える
4

Onion アーキテクチャ (または、@MystereMan がコメントで正しく指摘したように、少なくとも指摘したサンプル実装) には、注意すべき問題点があると思います。

アーキテクチャは小規模/焦点を絞ったインターフェイス (多くの場合、1 つのメンバーを持つ) を好むようですが、これらのサービスの命名はそうでないことを示しているようです。たとえば、リファレンス アーキテクチャにはIShippingServiceクラスがあります。メンバーが 1 つあるため、インターフェイス分離の原則(これは優れています) に準拠しています。ただし、「配送サービス」という名前は、配送に関連するすべての方法を含める必要があることを示しています。それは簡単に数十になります。ただし、このインターフェイスにメンバーを追加すると、インターフェイス分離の原則、単一責任の原則(SRP)、およびオープン クローズの原則が破られます。(OCP)。実装は、関係 (SRP) がほとんどまたはまったくないメソッドが多数あるため、大きくて醜いものになります。新しい配送要件を実装することは、メンバーを追加することを意味し、これは OCP を壊します。インターフェイスには多くのメンバーがありますが、コンシューマーはそれらのメンバーの 1 つを呼び出すだけでよく (凝集度が低い)、単体テストが難しくなります。

1 つのメンバーすべてを持つインターフェイスに分割すると、問題の一部は解決されます (そして、アーキテクチャにはこの意図がある可能性があります)。懸念事項 (ロギング、モニタリング、監査証跡、検証、トランザクション、フォールト トレランスなど) をそれらに切り詰めます。

これが問題であるかどうかは、多くの要因に依存しますが、SOLID原則の 1 つに違反することには常に注意が必要です。

したがって、Onion アーキテクチャへの追加として、この記事を読むことをお勧めします。この潜在的な欠点の解決策について説明しており、Onion アーキテクチャに適用できます。

于 2013-02-15T09:45:41.007 に答える