2

私はEntityFramework、WCF、および WPF に基づく新しい 3 層アプリケーションの私のチームの開発を支援するために、Dependency Injection ( Mark Seemann: .NETでの依存性注入およびさまざまな記事) を読んでいます。

サービス ( DAL <-> WCF <-> BL <-> WCF <-> PL / UI )を介して通信するため、各層にコンポジション ルートが必要であると想定しています。

私たちの要件の 1 つは、アプリケーションのデプロイ後にモデルを変更/拡張できるように、EF を動的にロードして構成する必要があることです。

BL --> PL/UI 実装の詳細には触れずに、カスタム serviceHost の背後にある EntityService を介して公開される DAL に注目しましょう。簡単な例を使用したプロジェクトは、次のようにレイアウトされています。

Project.DataModel

  • 単一のアセンブリ
  • ハード参照: なし
  • ランタイム解像度: なし
  • 抽象クラスとデータ モデリング用のインターフェイスを提供する共通ライブラリ。つまり、EntityData 抽象クラス

Project.DataModel.[?]データ

  • 多くのアセンブリ: CityData、CustomerData など
  • ハード参照: Project.DataModel
  • ランタイム解像度: なし
  • EntityData に基づく単一または複数のエンティティを定義するコンポーネント

Project.DataModel.[?]DataConfiguration

  • 多くのアセンブリ: つまり、CityDataConfiguration、CustomerDataConfiguration など
  • ハード参照: Project.DataModel.[?]Data、EntityFramework
  • ランタイム解像度: なし
  • 前のアセンブリで定義されたエンティティの EntityTypeConfiguration を定義するコンポーネント。

Project.DataAccess

  • 単一のアセンブリ
  • ハード参照: Project.DataModel、EntityFramework
  • 実行時の解決: Project.DataModel.[?]Data、Project.DataModel.[?]DataConfiguration
  • EntityManager(abstraction) を介して DbContext を提供するデータ アクセス ライブラリ。実行時に、このアセンブリは構成またはディレクトリを参照し、EntityTypes とそれに相当する EntityTypeConfigurations を読み込み、モデルを動的に作成します。

Project.ServiceModel.EntityDataService

  • 単一のアセンブリ
  • ハード参照: Project.DataModel、Project.DataAccess
  • ランタイム解像度: なし
  • EntityManager クラスを介して EntityData オブジェクトに対する CRUD 操作を提供する汎用サービス。

Project.ServiceModel.EntityDataServiceContract

  • 単一のアセンブリ
  • ハード参照参照: Project.DataModel
  • ランタイムの解決: Project.DataModel.[?]Data
  • サービス コントラクトを公開し、ServiceKnownTypes を定義する必要があるため、EntityTypes のランタイム解決が必要です。

Project.ServiceHost

  • 単一のアセンブリ
  • ハード参照: なし
  • 実行時の解決: Project.ServiceModel.[?]Service、Project.ServiceModel.[?]ServiceContract
  • EntityDataService などのさまざまなサービスを (構成またはディレクトリのスキャンを通じて) 実行時に解決して読み込むカスタム ServiceHost。

これは、コンパイル時にあまり知らず、アセンブリ間のハード参照があまりないプラグイン プロジェクトのように感じます。

このシナリオで DI をどのように実装しますか。DI や DI コンテナ、コンポジション ルート、ロットをどのように、どこで使用するかについて、私は本当に指を置くことができません。

ご意見をお待ちしております。

4

1 に答える 1

-1

人々は、依存性注入を過度に複雑にする方法を持っています。FirstClass が動作するために ISecondClass が必要な場合は、ISecondClass なしでは構築できないことを確認してください。コンポジション ルートは基本的に、依存関係を他のすべてのものまでたどることができるクラスです。すべてのインターフェイスにインスタンスが登録されていることを確認し (シングルトンの有効期間は通常、うまく機能します)、コンポジション ルートをインスタンス化すると、ほとんどのものが「正常に機能する」はずです。そうでない場合は、何かが必要以上に複雑になっています。

WizBang アプリケーションは次のようになります。

interface IThingDoerA
{
}

class ThingDoerA : IThingDoerA
{
}

interface IThingDoerB
{
}

class ThingDoerB : IThingDoerB
{
    private readonly IThingDoerA _tda;
    public ThingDoerB(IThingDoerA tda)
    {
        _tda = tda;
    }
}

interface IThingDoerC
{
}

class ThingDoerC : IThingDoerC
{
    private readonly IThingDoerA _tda;
    private readonly IThingDoerB _tdb;
    public ThingDoerC(IThingDoerA tda, IThingDoerB tdb)
    {
        _tda = tda;
        _tdb = tdb;
    }
}

// I am the composition root.
interface IWizBang
{
    public void StartApp();
}

class WizBang : IWizBang
{
    private readonly IThingDoerA _tda;
    private readonly IThingDoerC _tdc;
    public WizBang(IThingDoerA tda, IThingDoerC tdc)
    {
        _tda = tda;
        _tdc = tdc;
    }

    public void StartApp()
    {
        //TODO
        // _tda.Blah()
        // _tdc.Blah()
    }
}

WPF に関する限り、System.Windows.Application 子クラスでいくつかの軽量メソッド呼び出しを実行して、アプリを実行できるように見えます。

于 2012-06-07T03:12:23.500 に答える