我已经在 SO、书籍和文章中阅读了很多关于 DTO 的信息,但我不确定我是否正确。
我们在项目中使用 DTO,因此它们几乎只是域对象的属性。因此,我们需要有一个复杂的 DTO 结构。有一些类相互扩展,组合,聚合等。
问题更笼统。
从另一个 dto 继承一个 dto 或在另一个 dto 中引用一个 dto 是否正确?
我已经在 SO、书籍和文章中阅读了很多关于 DTO 的信息,但我不确定我是否正确。
我们在项目中使用 DTO,因此它们几乎只是域对象的属性。因此,我们需要有一个复杂的 DTO 结构。有一些类相互扩展,组合,聚合等。
问题更笼统。
从另一个 dto 继承一个 dto 或在另一个 dto 中引用一个 dto 是否正确?
从另一个继承 DTO 是否正确
如果它们具有共同的属性,那为什么不呢?
在 DTO 中有对另一个 DTO 的引用
这绝对没有错,请考虑以下几点:
public class UserDto
{
public string Id { get; set; }
public string Username { get; set; }
public string Email { get; set; }
public AddressDto Address { get; set; }
}
public class AddressDto
{
public string AddressLine1 { get; set; }
public string AddressLine2 { get; set; }
public string City { get; set; }
}
请记住,DTO 只是愚蠢的对象,即它们没有任何行为(除了获取/设置自己的数据)。从架构的角度来看,相同的规则适用于 DTO,就像它们适用于标准类/对象一样,所以如果可以的话,没有理由不遵循相同的原则。
DTO 用于层间通信。
我更喜欢简单的 DTO,因为它们主要用于告诉持久层,一般来说是数据访问对象,要存储什么。如果是这种情况,请不要选择复杂的 DTO。
如果 DTO 很复杂(即一个 DTO 具有另一个 DTO 作为属性),则 DAO 存储数据所需的复杂性更大。这与 DAO 作为与存储技术分离的方式的目标相冲突。
So, if a DTO needs to address another DTO, just use string ids as attributes and keep a simple DAO for each DTO. Logic to handle interconnected DTOs should go to the Service Application or Business Object making use of the DAOs. This way, you increase reuse of the code.