Question

对于请求和响应DTO，重复使用POCO是否正常（阅读良好实践）。我们的POCO是轻量级的（ORM Lite），只有属性和一些装饰属性。

或者，我应该为请求和/或响应创建其他对象吗？

谢谢，

Answer 1

我们有其他方法，我的回答是自以为是。

因为我们不仅使用C＃客户端，而且主要使用JavaScript客户端。

请求和响应DTO，路由和数据实体在

之间协商

客户和前端分析师。它们是详细形式的规格的一部分。

即使“客户”，在某些情况下，也是我们的产品用户界面。

这些DTO在没有重要原因的情况下不会改变，并且可以在双方重复使用。

但是数据层中的对象可以是相同或部分类或不同，

可以在内部更改它们，包括敏感信息或工作流信息，

但它们必须与API的规范兼容。

我们首先使用 API ，而不是数据库或ORM。

           Person  { ... }

           Address  { ... }

           ResponceDTO
           { 
             public bool success {get; set;}
             public string message {get; set;}
             public Person  person {get; set;}  
             public List<Address> addresses {get; set;}  
    //customer can use the Person & Address, which can be the same or different
   //with the ones in the data-layer. But we have defined these POCO's  in the specs.                           
            }
           RequestDTO
           { 
             public int Id {get; set;}
             public FilteByAge {get; set;}
            public FilteByZipCode {get; set;}
            }               
           UpdatePersonRequest
           { 
             public int Id {get; set;}
             public bool IsNew {get; set;}
             public Person  person {get; set;} 
             public List<Address> addresses {get; set;}   
            }

我们不会仅公开请求或响应DTO。

人员和地址是与客户协商的，并在API规范中引用。

它们可以与数据层内部实现相同或部分或不同。

客户将把它们用于他们的应用程序或网站，或移动。

但重要的是我们首先设计和协商API接口。

我们经常使用requestDTO作为业务层功能的参数，

返回响应对象或集合。

通过这种方式，服务代码是业务层前面的瘦包装器。

        ResponseDTO  Get(RequestDTO  request)
         {
                      return GetPersonData(request);
          }

同样来自ServiceStack wiki，API-First development方法

Answer 2

如果您可以公开数据对象的结构（如果这是一个公开使用的API），那么这不会成为问题。否则，Restsharp将与简单的POCO一起使用：）

Answer 3

我认为这一切都取决于你如何使用你的DTO，以及你希望如何平衡代码的可重用性和可读性。如果您的请求和响应都使用了DTO上的大部分属性，那么您将获得大量的可重用性，而不会降低可读性。例如，如果您的请求对象有10个属性（反之亦然），但您的响应只需要其中的1个，那么如果您的响应对象只有1个属性，则有人可以提出一个更容易理解/读取的参数

总之，良好的做法就是干净的代码。您必须评估您的特定用例，以确定您的代码是否易于使用和阅读。另一种思考方式是为下一个阅读它的人编写代码，即使那个人就是你。

ServiceStack请求和响应对象

3 个答案: