Web API 是否需要 ViewModels 层 类？
Web API is it necessary to have ViewModels layer classes?
当我使用 Web (MVC) 时，我总是创建一个单独的 类 层。这些 类 通常与 DTO 类 相同，但具有 [Display(Name = "Street")] 和验证等属性。但是对于web api Display 属性不是必须的，验证可以使用FluentValidation。 Api controller returns ViewModels 类 或 DTO 类 也可以吗？
实际上，这取决于应用程序的架构，我们希望如何 return 响应。在这种情况下，是的，我们可以 return DTO classes 但我认为这不是一个好方法，因为我们应该创建一个单独的资源 classes，它将与 DTO 映射，然后 return。请看下面的例子：
public class CustomerDTO
{
public int ID { get; set; }
public string Name { get; set; }
public int DepartmentId { get; set; }
}
public class CustomerResource
{
[JsonObject]
public string Name { get; set; }
[JsonObject]
public string Department { get; set; }
}
假设我们有 CustomerDTO class 并且我们想要 return 以以下 json 格式响应
{
"name":"Abc xyz",
"department":"Testing"
}
所以在这种情况下，我们应该有单独的 class，它将 return 作为对最终用户的响应，因为我创建了 CustomerResource。在这种情况下，我们将创建一个将 DTO 映射到资源对象的映射器。
而且通过这个实现我们可以独立测试资源
一如既往的答案......这取决于。
如果您的 API 服务于多个客户端、应用程序等，那么 returning DTO 是更好的选择。
ViewModels 是特定于 MVC 客户端的，应该已经为显示做好了准备，这意味着数据应该已经以特定的方式格式化，一些字段可能组合在一起，它们应该满足显示页面的任何要求。它们被称为 ViewNodes 是有原因的。关键是它们很少与 API return 的数据完全相同，后者应该更通用一些并遵循某种模式以使其用户理解。
如果您的 ViewModel 完全相同并且您只有一个客户端，那么是否要创建一组重复的分类只是为了避免具有属性，这取决于您。
从 DTO 到 ViewModel 的映射以及从 DTO 到 ViewModel 的映射并不十分复杂，但该过程确实引入了一个更复杂的过程，即多了一层。
不过不要忘记一件事。 API DTO 应该 return 他们在任何实体上拥有的数据，而不考虑任何 UI 的要求。无论如何，需求都可能发生变化，添加或丢弃新字段。当发生这种情况时，您很可能不理会 API，只需更改您的 ViewModels。
您的 ViewModel 特定于 UI 页面，并且应仅包含该页面所需的数据。这意味着您最终可以为相同的数据使用多个 ViewModel，只是每个 ViewModel 的显示要求不同。
我投票赞成将 ViewModel 和 DTO 分开，即使此时它们完全相同。事物总是在变化，这是您实际上可以做好准备的事情之一。
当我使用 Web (MVC) 时，我总是创建一个单独的 类 层。这些 类 通常与 DTO 类 相同，但具有 [Display(Name = "Street")] 和验证等属性。但是对于web api Display 属性不是必须的，验证可以使用FluentValidation。 Api controller returns ViewModels 类 或 DTO 类 也可以吗？
实际上，这取决于应用程序的架构，我们希望如何 return 响应。在这种情况下，是的，我们可以 return DTO classes 但我认为这不是一个好方法，因为我们应该创建一个单独的资源 classes，它将与 DTO 映射，然后 return。请看下面的例子：
public class CustomerDTO
{
public int ID { get; set; }
public string Name { get; set; }
public int DepartmentId { get; set; }
}
public class CustomerResource
{
[JsonObject]
public string Name { get; set; }
[JsonObject]
public string Department { get; set; }
}
假设我们有 CustomerDTO class 并且我们想要 return 以以下 json 格式响应
{
"name":"Abc xyz",
"department":"Testing"
}
所以在这种情况下，我们应该有单独的 class，它将 return 作为对最终用户的响应，因为我创建了 CustomerResource。在这种情况下，我们将创建一个将 DTO 映射到资源对象的映射器。 而且通过这个实现我们可以独立测试资源
一如既往的答案......这取决于。
如果您的 API 服务于多个客户端、应用程序等，那么 returning DTO 是更好的选择。
ViewModels 是特定于 MVC 客户端的，应该已经为显示做好了准备，这意味着数据应该已经以特定的方式格式化，一些字段可能组合在一起，它们应该满足显示页面的任何要求。它们被称为 ViewNodes 是有原因的。关键是它们很少与 API return 的数据完全相同，后者应该更通用一些并遵循某种模式以使其用户理解。
如果您的 ViewModel 完全相同并且您只有一个客户端，那么是否要创建一组重复的分类只是为了避免具有属性，这取决于您。
从 DTO 到 ViewModel 的映射以及从 DTO 到 ViewModel 的映射并不十分复杂，但该过程确实引入了一个更复杂的过程，即多了一层。
不过不要忘记一件事。 API DTO 应该 return 他们在任何实体上拥有的数据，而不考虑任何 UI 的要求。无论如何，需求都可能发生变化，添加或丢弃新字段。当发生这种情况时，您很可能不理会 API，只需更改您的 ViewModels。
您的 ViewModel 特定于 UI 页面，并且应仅包含该页面所需的数据。这意味着您最终可以为相同的数据使用多个 ViewModel，只是每个 ViewModel 的显示要求不同。
我投票赞成将 ViewModel 和 DTO 分开，即使此时它们完全相同。事物总是在变化，这是您实际上可以做好准备的事情之一。