我正在研究从客户呼叫的行动中更新实体的最佳实践。有几种方法可以做到这一点，但它们似乎都不是最好的做法。
1-获取将通过请求模型的反射更新的数据，并使用这些属性更新实体。但是反思并不建议在web api中使用。
2-将实体的所有数据发送到客户端，并从请求中获取更新版本。这似乎造成了不必要的交通。
3-获取将要更新的数据并使用if else条件检查它们以获取更改的数据。它是如此基本而非通用，似乎非常不专业。
我所谈到的请求模型是实体模型的克隆。
答案 0 :(得分：3)
首先，不要使用Reflection。这很慢，让你的代码更加脆弱。
对于EF，通常有3种可能的解决方案：
1;客户端发送整个更新的实体，仅发送更新的实体。在这种情况下，您只需将实体附加到相应的实体集，并将实体状态标记为已修改。
2;客户端发送原始实体和更新的实体。附加原始文件并将当前值设置为更新实体。
3;客户端仅发送修改后的属性，而不是整个实体。在这种情况下，您必须从数据库中查询原始实体并逐个设置属性或再次覆盖当前值。
3种方法的带宽要求和查询次数不同。
1;如果我们将此作为基线，则它有一个带宽要求从客户端向服务器发送一个实体，然后将这一个实体从服务器发送到数据库。这使得1 db查询altogehter（附加不需要查询，因此只有保存更改部分才会启动查询）。
2;这具有从客户端向服务器发送两个实体的带宽。在这里，您必须将较少的数据从服务器发送到数据库，因为在设置当前值时会计算更改的属性。同样，只有1个查询（附加和设置当前值不会启动查询，因此只有保存更改部分会创建查询）。
3;这从客户端到服务器以及从服务器到数据库的带宽要求最低（两次都只发送更改的属性）。但是，除了保存之外，还需要一个查询，因为在设置更改之前，您必须从数据库中查询原始值。
我通常发现第一种方法是在另外两种方法之间进行良好的权衡。它确实发送的数据多于第三个，但仍然小于第二个，它只启动一个查询来保存数据。此外，我喜欢最小化客户端和服务器之间的流量，即使这意味着服务器和数据库之间有更多的流量。客户（至少对我而言）通常是移动的，所以没有保证带宽，没有保证电池寿命。服务器和数据库更接近＆＃34;他们没有这些限制。但是，对于您的应用程序来说，这当然有所不同。