c# - ServiceStack请求和响应对象

Question

可以将POCO重复用于请求和响应DTO吗？我们的POCO是轻型的（ORM Lite），仅具有属性和一些装饰属性。

还是应该为请求和/或响应创建其他对象？

谢谢，

Answer 1

我要说的是，这取决于您的系统，最终取决于它现在的规模和复杂程度，并具有发展的潜力。

ServiceStack文档未指定您应使用的设计模式。最终，它提供了将数据库模型POCO与DTO分离的灵活性，但同时也为其重用提供了支持。

使用OrmLite时：

OrmLite的设计旨在使您可以将数据模型POCO用作您的请求和响应DTO。 As noted from the ServiceStack documentation，这是框架的故意设计目标：


  微型ORMS中使用的POCO特别适合作为DTO重新使用，因为它们不包含重型ORM具有的任何循环引用（例如EF）。 OrmLite再走1步，并从NoSQL的剧本中借用页面，其中包含任何复杂的属性，例如List在无模式的文本字段中透明地被填充，从而促进了不受RDBMS关注的无摩擦Pure POCOS的设计。


考虑：

如果您确实选择重用POCO（因为受支持），则应注意在某些情况下使用单独的请求和响应DTO会更明智。


  在许多情况下，这些POCO数据模型已经构成了良好的DTO，可以直接返回，而不必映射到特定于域的DTO。


^并非所有情况。有时，选择设计模式的困难在于预见可能不适合重用的情况。因此，希望有一个方案可以帮助说明潜在的问题。

场景：


您有一个系统，用户可以在其中注册您的服务。
您作为管理员可以列出您的服务用户。


如果您采用OrmLite POCO重用方法，那么我们可能会有以下User POCO：

public class User
{
    [PrimaryKey, AutoIncrement, Alias("Id")]
    public int UserId { get; set; }
    public string Username { get; set; }
    public string Password { get; set; }
    public string Salt { get; set; }
    public bool Enabled { get; set; }
}

发出“创建用户”请求时，将您的 Username POCO的 Password和 User填充为对服务器的请求。

我们不能仅仅将POCO推送到数据库中，因为：


Password字段中的密码将为纯文本。我们是优秀的程序员，并且安全性很重要，因此我们需要创建一个添加到 Salt属性中的盐，并使用盐对 Password进行哈希处理并更新 Password字段。好的，这不是主要问题，几行代码会在插入之前对其进行排序。
客户端可能已经设置了 UserId，但是对于创建来说不是必需的，这将导致我们的数据库查询无法插入。因此，在插入数据库之前，我们必须默认此值。
Enabled属性可能已随请求一起传递。如果有人设置了该怎么办？我们只希望处理 Username和 Password，但是现在我们必须考虑可能影响数据库插入的其他字段。同样，他们可以设置 Salt（尽管这不会有问题，因为无论如何我们都将覆盖该值。）因此，现在您添加了验证功能。


但是现在考虑何时返回 List<User>。

如果您将POCO重新用作响应类型，则有很多字段您不想公开给客户端。这样做并不明智：

return Db.Select<User>();

由于您没有针对列出用户列出的严格目的的响应，因此需要在逻辑中删除 Password哈希和 Salt，以防止其在响应中被序列化。

还请考虑在用户注册期间，作为创建请求的一部分，我们要询问是否应该发送欢迎电子邮件。因此，我们将更新POCO：

public class User
{
    // Properties as before
    ...
    [Ignore] // This isn't a database field
    public bool SendWelcomeEmail { get; set; }
}

现在，我们有了仅在用户创建过程中有用的附加属性。如果您一遍又一遍地使用 User POCO，随着时间的推移，您会发​​现您添加的越来越多的属性不适用于某些上下文。

例如，当我们返回用户列表时，现在可以填充 SendWelcomeEmail的可选属性-只是没有意义。这样可能很难维护代码。

要记住的关键是，在共享POCO对象以使其同时用作请求和响应对象时：作为响应发送的属性将在请求中公开。您将必须对请求进行更多的验证，最终共享POCO可能不会省力。

在这种情况下，这样做会容易得多：

public class CreateUserRequest
{
    public string Username { get; set; }
    public string Password { get; set; }
    public bool SendWelcomeEmail { get; set; }
}

public class UserResponse
{
    public int UserId { get; set; }
    public string Username { get; set; }
    public bool Enabled { get; set; }
}

public class User
{
    [PrimaryKey, AutoIncrement, Alias("Id")]
    public int UserId { get; set; }
    public string Username { get; set; }
    public string Password { get; set; }
    public string Salt { get; set; }
    public bool Enabled { get; set; }
}

现在我们知道在创建请求（ CreateUserRequest）时不必考虑 UserId， Salt或 Enabled。

当返回用户列表时，它现在是 List<UserResponse>，客户端将不可能看到我们不希望他们看到的任何属性。

对于其他人来说，查看代码，请求所需的属性以及将在响应中公开的内容很明显。

摘要：

抱歉，这是一个很长的答案，但是我认为这解决了共享POCO的一个问题，有些人错过了或者一开始无法掌握，我就是其中之一。


是的，您可以重新使用POCO进行请求和响应。
文档说这样做是可以的。实际上，这是设计使然。
在许多情况下，可以重新使用。
在某些情况下不合适。 （我的场景试图证明这一点，但是当您开发自己的实际情况时，您会发现。）
考虑由于共享的POCO尝试支持多个操作而可能会公开多少个其他属性，以及可能需要多少额外的验证工作。
归根结底，这取决于您是否愿意维护。


希望这可以帮助。