0

これは明確な答えがある質問ではありませんが、私のアーキテクチャについてアドバイスが必要です。このトピックについては、さまざまな意見があるかもしれません。

アーキテクチャを愚かなエンティティから豊富なドメイン オブジェクトに移行しようとしています。現在のバージョンでは、ビジネス ロジックを表す読み取り専用のプロパティとメソッドを持つ抽象ドメイン オブジェクトがあります。

abstract class Project
{
  public string PropertyName { get; protected set; }
  public void Setup(SetupData data)
  {
    ...
    Save();
  }
  protected abstract void Save();
}

それらから派生して、永続エンティティへのマッピングを実装し、保存ロジックを実装します。

class MongoProject
{
  MongoProject(ProjectDocument document, Action<ProjectDocument> save)
  {
    MapFrom(document);
  }
  public override Save()
  {
    MapTo(document);
    save(document);
  }
}

これは非常に簡単に機能します。パブリック セッターがなく、ドキュメントとのマッピングであってもテストできるため、プロジェクトは常に有効です。

しかし、私はいくつかの問題にも気付きました:

  1. 私はいつもいくつかのプロパティをマッピングするのを忘れていました.MongoProjectに何をシリアル化する必要があるかを伝える方法はありません.
  2. プロジェクトが複雑な集約ルートである場合は特に、save メソッド内で何が変更されたかわからないため、マッピングの実装が比較的複雑になることがあります。私の状況では、mongodb で永続性を実装するのは非常に簡単でしたが、エンティティ フレームワークでは悪夢でした。

アプリケーションの永続性をどのように解決しますか?また、マッピングの問題に対する他の解決策はありますか?

4

1 に答える 1

0

これは少し広い質問です。

ドメイン オブジェクトとデータ アクセス レイヤー (データベース、ファイル、クラウドなどに保存) を同じクラスに実装することはありません。関心の分離が必要です。ドメイン オブジェクトは、自分自身をデータベースに保存する方法を知る必要はありません。

私がすることは、クラス内にドメインオブジェクトを作成し、別のデータアクセスレイヤーを作成することです。これは、データを保存したいソースにデータを保存する責任があります。そうすれば、エンティティを別の場所に保存するたびに、オブジェクト モデルは気にせず、変更する必要がまったくありません。

POCO オブジェクトを DB エンティティにマッピングするには、AutoMapperを使用します。これにより、ボイラープレート コードが大幅に節約され、一度設定するだけで済みます。

例えば：

// Domain object
public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

// Data Access Layer
public class MongoAccessLayer : IDal
{
    public void SaveEntity<T>(T entity)
    {
        // Save logic here
    }

    public void LoadEntity<T>(T entity)
    {
    // Load logic here
    }
}

// Interface defining what the access layer should look like
public interface IDal
{
    void SaveEntity<T>(T entity);
    void LoadEntity<T>(T entity);
}
于 2014-05-26T16:22:35.253 に答える