设计ApiController，Viewmodel和DTO

Question

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

服务器

• Asp.Net WebApp（托管本地或天蓝色）
• EntityFrameworkCore Datalayer
• 带有控制器的WebApi，用于每个EF模型，发送平面DTO

客户端

• ApiClient，接收DTO
• 每个视图的视图模型（MVVM），使用多个不同的DTO。实体之间的关系需要通过实体ID手动连接。

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

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

Answer 1

我认为你可以抽象出你在互联网上阅读的关于架构的想法，一个好的架构实际上是能够以更有效的方式解决你的问题的架构。 我的建议是不要坚持这些架构，敞开心扉，跳出框框思考。你可以创建一个API控制器，或者你可以创建一个Proxy类（http://www.dofactory.com/net/proxy-design-pattern）来抽象那些api调用。

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

  

实体框架的舒适Linq语法不可用于   客户端。包装所有的东西是否有类似的东西   “接收 - 创造和关系”的东西？

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

Answer 2

  

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

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

  

实体框架的舒适Linq语法在客户端不可用。有没有类似的东西包含所有＆＃34;接收 - 创造 - 关系＆＃34;东西

DTO不是必须的。它内部可能有其他对象。如果您使用JSON序列化程序将数据传递到客户端，则应将DTO反序列化为Javascript对象，并保留所有关系。另请检查underscorejs库。它有许多有用的功能，可以像LINQ一样使用Javascript对象。