私のオブジェクトが実装できる複数のインターフェイスがあります。同じメソッド名を使用しながら、ある拡張メソッドを別のメソッドに「カスケード」する方法があるのだろうかと思います。私はこのすべて間違っを見ていますが、ここでは一例であることがあります。複数のインターフェイスのカスケード拡張メソッド?
public interface IBaseDto
{
int Id {get;set;}
string CreatedByFullName {get;set;}
}
public interface IDocumentDto
{
List<ContactDto> Subscriptions {get;set;}
}
public class ContactDto: IBaseDto
{
public int Id {get;set;}
public string CreatedByFullName {get;set;}
public string FirstName {get; set}
public string LastName {get;set;}
}
public class MeetingDto: IDocumentDto
{
public int Id {get;set;}
public string CreatedByFullName {get;set;}
public List<ContactDto> Subscriptions {get;set;}
}
それでは、私は拡張メソッドを使用してエンティティへのDTOを変換したいとしましょう。例はMeetingDto.ToEntity()
です。 の拡張メソッドの一部、IDocumentDto
の拡張メソッドを記述して、それぞれ固有のプロパティの具体的な実装について記述できるかどうかを考えようとしています。 MeetingDto.ToEntity()
と呼ぶと、最初に会議の延長方法に当たってIDocumentDto
バージョンを呼び出し、必要な情報を入力してから、IDocumentDto
はIBaseDto
となります。私はこれが理にかなってほしい。
UPDATE:
私はこの思い付いたし、それはかなりうまく機能:
public static TBaseDto ToEntity<TBridgeDto>(this TBaseDto dto) where TBaseDto: IBaseDto
{
...
return dto;
}
public static TDocumentDto ToEntity<TDocumentDto>(this TDocumentDto dto, IDocumentDto currentDto) where TDocumentDto : IDocumentDto
{
...
return dto.ToEntity();
}
public static MeetingDto ToEntity(this RfiDto dto)
{
...
return dto.ToEntity(dto)
}
なぜ拡張メソッドを使用しますか? 'ToEntity()'メソッドが他のところで定義されているので、あなたのDTOがよりクリーンであると思いますか? IBaseDTOのToEntity()メソッドがそれぞれの子クラスによってオーバーライドされることが理想的であることを示唆しているようです。ちなみに、MeetingDtoはIBaseDTOも継承する必要がありますか? – perfectionist
automapperはあなたの友人かもしれません。 –
@ DanielA.White、私は私のDTOを生成するためにAutomapperを使用していますが、DTOからEntitiesに行くのは問題です。加えて、私たちが行っているマッピングプロパティの外にいくつかのものがあります。 – DDiVita