ApiController、Viewmodel 和 DTO 的设计

Question

我正在计划一个“通用”客户端-服务器-架构。当前的结构如下所示：

服务器

• Asp.Net WebApp（托管在本地或 Azure 中）
• EntityFrameworkCore 数据层
• WebApi 与每个 EF 模型的控制器，发送平面 DTO

客户

• ApiClient，接收 DTO
• 每个视图 (MVVM) 的视图模型，与多个不同的 DTO 一起使用。 Entity 之间的关系需要通过 Entity-ID 手动连接。

正如许多教程所示，这就是要走的路。但我不确定某些事情。

• 从我的 ViewModel 调用我的 Api 时，我需要多次调用（我需要的每个实体一个）。为我的 ViewModel 创建一个 ApiController 会不会更快，它可以在一次调用中为我提供所需的一切？我猜这违反了常见的模式，但有什么反对的呢？整个客户端逻辑在服务器上执行，客户端保持干净和愚蠢。
• 实体框架的舒适 Linq 语法在客户端不可用。是否有一个类似的东西来包装所有“receive-dto-and-create-relations”的东西？

Answer 1

我认为您可以将您在互联网上阅读的有关架构的想法抽象出来，一个好的架构实际上是可以更有效地解决您的问题的架构。 我的建议是不要拘泥于那些架构，敞开心扉，跳出框框思考。您可以创建一个 API 控制器，也可以只创建一个代理类 (http://www.dofactory.com/net/proxy-design-pattern) 来抽象这些 api 调用。

另一种方式，您可以在 api 端加入数据。使用 api 返回与唯一实体相关的数据不是强制性的。您可以创建另一个类并按照您需要的方式对数据进行建模。

实体框架的舒适 Linq 语法在 客户端。有没有类似的东西包裹着所有 “接收-dto-and-create-relations”的东西？

嗯，你总是可以使用 lambda 表达式来查询你的数据，当你使用 .net 集合时，它非常类似于实体框架 linq，唯一的区别是你不是直接从数据库中操作数据, 仅在内存数据中。

Answer 2

从我的 ViewModel 调用我的 Api 时，我需要多次调用（我需要的每个实体一个）。为我的 ViewModel 创建一个 ApiController 会不会更快，因为它可以在一次调用中为我提供所需的一切？我猜这违反了常见的模式，但有什么反对呢？整个客户端逻辑在服务器上执行，客户端保持干净和愚蠢。

这并不违反常见的模式。根据您的用例创建您的 API 方法并返回您需要的所有数据。看起来您正在尝试创建一个 RESTful API，但 REST API 不必只是普通的 CRUD API。任何东西都可以是资源。

实体框架的舒适 Linq 语法在客户端不可用。是否有类似的东西包装所有“接收-dto-and-create-relations”的东西

DTO 不需要平坦。它里面可能有其他对象。如果您使用 JSON 序列化程序将数据传递给客户端，您的 DTO 应该被反序列化为保留所有关系的 Javascript 对象。还要检查underscorejs 库。它有许多有用的函数可以以类似 LINQ 的方式处理 Javascript 对象。