在Web Api中更新实体的最佳实践

Question

我正在研究从客户要求的操作更新实体的最佳做法。 有几种方法可以做到这一点，但似乎没有最佳实践。

1-从请求模型中获取将通过反射更新的数据，并使用这些属性更新实体。 但是不建议在Web API中使用反射。

2-将实体的所有数据发送到客户端，并从请求中获取其更新版本。 似乎造成不必要的流量。

3-获取将要更新的数据，并检查是否有其他条件更改获取哪些数据。 它是如此基础而不是通用，似乎如此不专业。

我所说的请求模型是实体模型的克隆。

Answer 1

首先，不要使用反射。 它像地狱一样缓慢，并使您的代码更加脆弱。

对于EF，通常有3种可能的解决方案：

1; 客户端发送整个更新的实体，并且仅发送更新的实体。 在这种情况下，您只需要将实体附加到相应的实体集，然后将实体状态标记为“已修改”。

2; 客户端发送原始实体和更新的实体。 您附加原始文件并将当前值设置为更新实体。

3; 客户端仅发送修改后的属性，而不发送整个实体。 在这种情况下，您必须从数据库查询原始实体，并一一设置属性，或者再次覆盖currentvalue。

这三种方法的带宽要求和查询数量不同。

1; 如果我们以此为基准，则对带宽有一个要求，即从客户端向服务器发送一个实体，然后从服务器向数据库发送一个实体。 这样就可以进行1 db查询（附加不需要查询，因此只有保存更改部分才能启动查询）。

2; 它具有将两个实体从客户端发送到服务器的功能。 在这里，您必须将更少的数据从服务器发送到数据库，因为更改的属性是在设置currentvalue时计算的。 同样，只有1个查询（附加和设置currentvalue不会启动查询，因此只有保存更改部分才能创建查询）。

3; 从客户端到服务器以及从服务器到db的带宽需求最少（两次仅发送更改的属性）。 但是，除了保存之外，还需要再执行一次查询，因为在设置更改之前，您必须从数据库查询原始值。

我通常发现第一种方法是在其他两种方法之间进行权衡。 它确实发送了比第三次更多的数据，但仍然少于第二次，并且仅启动一个查询以保存数据。 我也想最小化客户端和服务器之间的流量，即使这意味着服务器和数据库之间的流量更大。 客户端（至少对我而言）通常是移动的，因此不保证带宽，也不保证电池寿命。 服务器和数据库“更紧密”，它们没有这些限制。 但是，当然这对于您的应用程序可能有所不同。