I'm a bit concerned are how much redundancy there is between some DTOs and their entities . For example, a CustomerEntity could be
public class Customer: Entity
{
[Required]
public string Name {get;set;}
public int CategoryId {get;set;}
public virtual Category Category {get;set;}
}
and its input DTO
public class Customer: IInputDTO
{
public int Id {get;set} // this could be aproblem
[Required]
public string Name {get;set;}
public int CategoryId {get;set;}
}
I'm especially concerned about having to maintain twosets of identical annotations.
So, I'm wondering about creating an abstract customer
public abstract Abstractcustomer:Entity
{
[Required]
public string Name {get;set;}
public int CategoryId {get;set;}
}
And having entities and (relevant) DTOs inherited from it. Is there any problem with this idea ?
2 Answer(s)
-
0
I did not do it before. It seems an alternative approach. The problem here is your DTO will be derived from Entity. I would not do it for my application, but could not see a major problem now (did not think much on it :)).
-
0
Yes, I'm a bit bothered about deriving from Entity for my DTO. I'm wondering if I'm going to create a MyEntity implementing IEntity just so I can play with attributes. Not sure too.
Thanks for your answer !
