3

私たちはしばらく Automapper を使用してきましたが、非常に便利だと思います。作成していただきありがとうございます!

ただし、質問があります。

質問

「ソース プロパティを内部宛先プロパティにマップするように AutoMapper をどのように構成しますか?」

バックグラウンド

レイヤード アーキテクチャでは、Dto オブジェクトがデータ アクセス レイヤーを離れることはなく、データ アクセス レイヤーを出入りできるのはドメイン オブジェクトだけです。したがって、ドメインの POV からすると、ドメイン オブジェクトにはデータベースの知識が含まれていてはなりません。ただし、実際には、データベース ID は持ち歩くのに非常に便利です。「ビジネス層」の開発者は ID について知らないはずです。

解決策: データベース ID をドメイン オブジェクトに追加しますが、「ビジネス レイヤー」に公開されないように内部として販売します。次に、(ドメイン オブジェクトを所有する) 共通層の内部をデータ アクセス層に公開します。問題が解決しました。Automapper (> v3.3.0) を内部プロパティで動作させる方法がわからないことを期待してください。

では、バージョン 3.3.0BindingFlagsが公開されており、これを使用して問題を解決しています。

例

Common.DLL

public class Person
{
   public Parent Father { get; set; }
   internal int FatherId {get; private set; }
}

DataAccess.dll

internal class PersonDto
{
   public ParentDto Father { get; set; }
   public int FatherId {get; private set; }
}

Profile クラスには、CreateMap<PersonDto, Person>();

編集 1 - 父の戻り型のタイプミスを修正しました。

編集 2 - 詳細情報を追加..

Common.Dll には、次のようなサービスがあります。

public class ParentService
{
    public Parent GetFather(Person person)
    {
        return repo.Parents.FirstOrDefault(parent => parent.Id = person.Father.Id);
    }
}

Business.Dll では、次のようなサービスを使用する開発者がいます。

var father = parentService.GetFather(son);
// use father separately or assign it to the son. Like so:
// son.Father = father;

重要なのは、ビジネス開発者がson.FatherIdBusinssess.Dll からアクセスしたり、ドメイン オブジェクトを作成した Dto オブジェクトにアクセスしたりしたくないということです。

したがって、すべての「データベース」の知識は、さまざまな Common.dll サービスまたは DataAccess.dll 内にカプセル化されます。

ありがとう。

4

1 に答える 1

3

この質問はここで回答されています。

便宜上、答えを引用します。

初期化メソッドで構成オブジェクトの ShouldMapProperty プロパティを設定するだけです。

これは静的 API を使用した例ですが、非静的 API を使用して同様の方法で同じことを実現できるはずです。

Mapper.Initialize(i =>
{
    i.ShouldMapProperty = p => p.GetMethod.IsPublic || p.GetMethod.IsAssembly;
    i.CreateMap<Source, Target>();                
});
于 2016-05-23T18:23:43.893 に答える