3

仲間の開発者と私は (軽く言えば) オブジェクトのプロパティの遅延読み込みについて話し合っています。

  • 彼は、オブジェクトのオブジェクトの解決と遅延ロードに静的 IoC ルックアップ呼び出しを使用すると述べています。
  • それは SRP に違反し、所有する Service を使用してそのオブジェクトを解決すると言います。

では、IoC と SRP に続く遅延読み込みをどのように処理しますか?

その遅延ロードされたプロパティを単体テストすることはできません。彼は、「あなたはすでに UserStatsService の単体テストを持っています。あなたのコード カバレッジがあります」と反論しています。有効なポイントですが、プロパティは「完全な」カバレッジのためにテストされていません。

セットアップ / コード パターン:

  • プロジェクトは、厳密な依存性注入ルールを使用しています (すべてのサービス、リポジトリなどの ctor に注入されます)。
  • プロジェクトはキャッスル経由で IoC を使用しています (ただし、Unity など、何でもかまいません)。

以下に例を示します。

public class User
{
  public Guid UserId { get; set; }

  private UserStats _userStats;
  // lazy-loading of an object on an object
  public UserStats UserStats
  {
    get
    {
      if (_userStats == null)
      {
        // ComponentsLookup is just a wrapper around IoC 
        // Castle/Unity/etc.
        _userStats = 
          ComponentsLookup
            .Fetch<UserStatsService>()
              .GetByUserId(this.UserId);
      }
      return _userStats;
    }
  }
}

上記は、オブジェクトの遅延ロードの例を示しています。これを使用しないで、そのオブジェクトが必要な場所ならどこでも UI レイヤーから UserStatsService にアクセスするように言います。

編集：以下の1つの答えは、遅延読み込みに対するNHibernateのトリックを思い出させました。これは、プロパティを仮想化し、NHibernateが遅延読み込み自体の過負荷を作成できるようにすることです。はい、スリックですが、NHibernate は使用していません。

遅延読み込みの問題に実際に取り組んでいる人は誰もいません。いくつかの良い記事と SO の質問が近づいています。

遅延読み込みの利点は確かにあります。誤解しないでください。忍者の DI 方法に切り替えるまで、複雑な型とそのサブタイプを遅延読み込みするだけでした。利点は、ユーザーの統計情報が表示される UI レイヤーにあります。たとえば、100 行のリストです。しかし DI では、数行のコードを参照してユーザーの統計情報を取得する必要があり (SRP に違反したり、デメテルの法則に違反したりしないようにするため)、この長い検索パスを 100 回以上実行する必要があります。

はい、キャッシュを追加し、UserStatsService がシングルトン パターンとして使用されるようにコード化されていることを確認すると、パフォーマンス コストが大幅に削減されます。

しかし、IoC と DI のルールに完全には従わず、回避策を正当化するための有効なパフォーマンス/コーディング ポイントを持っている [頑固な] 開発者が他にいるかどうか疑問に思っています。

4

1 に答える 1