1

私はまだ OOP の概念と依存性注入に少し苦労しているので、ご容赦ください。

User テーブルを使用して Linq2Sql モデルを生成しました。このユーザーに確認メールを送信できるようにしたいので、User オブジェクトの部分クラス ファイルを作成し、SendConfirmationEmail() メソッドを追加するのが自然だと感じました。ユーザークラスに。このメソッドは MailService を使用して実際の電子メールを送信し、依存性注入を使用してサービスを渡したいので、このように User オブジェクトにコンストラクターのオーバーロードを作成しました

public User(IMailService service) : this()
{
    _service = service;
}

SendConfirmationEmail メソッドは次のようになります。

public void SendConfirmationEmail()
{
    _service.SendMail(params...);
}

私はこれが一種の貧弱な依存性注入であることを認識しており、後で依存性注入フレームワークに切り替えたいと考えています。

私にとっての問題は、モデル dll からサービス dll への参照を作成する必要があることです。これは正しくないようです。また、linq2sql で生成されたエンティティが依存性注入フレームワークと OOP の概念とどのように連携するかがよくわからないためです (ninject のように見えると思います)。最も有望です）。

私がこれで正しい方向に進んでいるかどうか、私が言うことができるよりも少し多くの経験を持つ誰かを望んでいました. 私はそれを機能させることができることを知っていますが、同じステップで正しい方法でそれを行うことについて自分自身を教育したいと思います.

4

3 に答える 3

2

私は個人的にあなたのアーキテクチャのいくつかのことを変更します：

  • SendConfirmationEmailをUserオブジェクトのメソッドにするべきではないと思います。ただし、ユーザーをパラメーターとして使用する別のオブジェクトのメソッドである必要があります。（これにより、Dalが他のロジックからより適切に分離されます。

  • このメソッドの2番目は、次のようなものを使用します。

    Services.Get <IMailService>（）。SendMail（params ...）;

サービスをfolowinとして実装できます（単なる例）。

public class Services
{
    protected static Dictionary<Type, object> services = new Dictionary<Type, object>();

    private Services() 
    {
    }

    static Services()
    {
        // hard coded implementations...
        services.Add(typeof(IMailService), new DefaultMailServiceImplementation());
    }

    public static T Get<T>() where T : class
    {
        Type requestedType = typeof(T);
        return services[requestedType] as T;
    }
}

「サービス」クラスを使用する（または好きな名前を付ける）ことで、IOCフレームワークとコードの間にレイヤーを追加し、IOCフレームワークを簡単に変更できるようにします。Getメソッドの実装を変更するだけで使用できます。静的コンストラクターで（上記の例で行ったように）ハードコードされた一時的なソリューションを（IOCフレームワークを使用するまで）使用することもできます。

于 2009-01-05T13:56:31.140 に答える
1

これは問題ないと思いますが、将来のクロスレイヤー依存関係の問題から身を守るために、さらに2つのことを行うことをお勧めします。

  1. Userオブジェクトのインターフェースを作成します。そうしないと、このビジネスオブジェクトを消費するすべてのものがLINQ dllを不必要に参照する必要があるため、これを行う必要があります。
  2. 依存性注入をコンストラクターからプロパティに移動します。これを行うのは、コンストラクターインジェクションがオブジェクトを動的に作成する能力を制限する傾向があるためです。ただし、これを行うと問題が発生します。これは、のnullチェックコードを多数実装する必要があるため_serviceです。これを修正するには、IMailServiceの「空の」実装を作成し、それを_serviceのデフォルト値にします。
于 2009-01-05T13:53:10.617 に答える
1

このアプローチの問題は、ほとんどの場合、エンティティが LINQ-to-SQL バックエンドから取得されるため、コンストラクターを使用しないことです (LINQ-to-SQL は独自の方法でオブジェクトを作成します)。 ; LINQ-to-SQL にコンストラクターの使用を強制することはできません) - これは、自分で作成した (少数の) オブジェクトにのみ役立ちます。データ バインディング (など) も、通常、既定でパラメーターなしのコンストラクターを使用します。

これは、サービスを受け入れるか、ファクトリ/シングルトンを介してサービス自体を取得するユーティリティ メソッドとしてうまく機能しないのではないかと思います。

于 2009-01-05T12:56:58.920 に答える