Question

同事正在使用＆＃34;实体和Dtos＆＃34;在我们的应用程序中实现Repository模式。这是他的想法，我不熟悉这些习语。

目前，实体和Dtos之间的主要区别是：

实体有一个ID字段（Dtos也有，我发现它很臭）;
Dtos有Clone方法;
实体属性具有更加序列化的数据类型，转换由数据映射器执行;

问题是：

我应该在客户端自由创建我的Dtos，然后将它们发送到回购站吗？或者我应该在repo界面上要求新的Dto实例吗？

这将是：

之间的区别

TDto dto = new TDto();
// edit dto properties
repo.Add(dto)

和

TDto dto = repo.Add(); // repo : Repository<TDto>
// edit dto properties
repo.Update(dto);

有一种优选方式吗？如果这是一个偏好问题，我更喜欢第二种选择，我是否应该注意不要把自己画到某个角落？

（免责声明：坦率地说，我认为这个Entity / Dto对于我们相对简单的客户端桌面应用程序来说是过度的，它只有基于序列化的简单CRUD需求，但我愿意遵循＆＃34;模式＆＃34; as只要它解决问题而不是阻碍问题）

更新：

我目前面临并试图解决的一个问题是＆＃34; Smelly Id Property＆＃34;。目前，Id在添加时设置在Dto中。代码是这样的：

    public Patient Add(Patient patient)
    {
        patient.Id = Guid.NewGuid();
        var entity = patient.ToEntity();
        _patientsCache.Add(entity);
        this.Salvar();
        return patient;
    }

请注意，方法调用返回相同的Dto，现在只将其Id设置为repo创建的值。我的头脑看着这个并且认为＆＃34;这是不对的＆＃34;，但我无法令人信服地证明它。

Answer 1

最终，在复杂性和架构决策方面，没有“正确”的答案。正如您所指出的，如果应用程序很小，那么在其中设计太多层可能会过多。另一方面，如果应用程序的大小增加，则稍后重构会更难。

关于在何处实例化DTO的问题;它只是实例化。如果你正在调用默认构造函数，并且你的构造函数表现得很无异常 - 也就是说它没有执行复杂逻辑或做有副作用的事情，而只是设置你的默认或“空”实例DTO - 那你在哪里做真无所谓。

我会说在客户端这样做，因为它更简单，可以为您节省一次往返。

如果您不希望您的客户知道DTO中的“ID”字段，请将其设为internal字段或属性，并将其设置在存储库代码中。

我应该在存储库界面之外创建存储库项吗？

1 个答案: