在哪里管理多层应用程序中的实体状态更改？答案

【问题标题】：Where to manage entity state change in multi tier application?在哪里管理多层应用程序中的实体状态更改？
【发布时间】：2017-07-09 15:50:47
【问题描述】：

我在 .Net/C#/EF6/WPF/WCF 中构建了一个多层应用程序。

后端是一个mysql数据库，带有实体框架层来访问数据库。我有一个业务逻辑层和一个外观层来公开服务。

在客户端，一个 WPF/MVVM 客户端。

我有 3 个模型，一个用于客户端（“视图域”），一个用于实体框架生成的后端（“db 域”），一个用于服务的类 dto。

在客户端，我跟踪实体状态的变化，我基本上从System.Data 复制EntityState 枚举，并在属性更改或创建新实体时设置状态。

例如，我的一项服务公开了Add(Entity e) 和Update(Entity e)。

我应该决定在客户端调用一个或另一个方法（他知道状态是Added 还是Modified）还是我应该公开一个名为AddOrUpdate(Entity e) 的方法并让后端决定它是否是一个新的或更新的实体？

最好的方法是什么？我应该在客户端还是后端做出决定？

【问题讨论】：

如果你有多层应用程序并且有一个数据访问层，你应该在数据访问层验证和控制行的状态，但是在实体框架中你不需要控制实体的状态（比如数据集state) 并且您可以调用 save changes 来提交所有更改，但是如果您需要控制状态，您可以在外观中控制它，然后决定最常调用哪种数据访问或规则层方法
对我来说，一个更重要的问题是客户是否应该进行变更跟踪。从技术上讲，客户端总是有陈旧的数据，因此每个数据点都可能被“修改”，即使客户端不知道。只有服务器适合比较当前状态。此外，服务不能相信每个客户端都做对了，所以它总是必须检查/验证更改。
你有两种方式来很好地控制状态 1. 你可以在外观中控制状态，然后如果你需要调用规则层和规则调用数据访问层，如果你需要返回一个错误到表示层你不需要去规则或数据访问层...... 2.另一种方法可以使用http模块来检查这种情况。在这种情况下，您没有虚假的服务电话...

【解决方案1】：

不确定您为什么希望客户端知道/处理对象的状态。
您的问题可能是因为您在这两种方法中重用了“实体”类。

我认为你可以使用这样的东西：

 Add(InputResource e) 
 Update(UpdateResource e)

以上都不应该有“状态”属性*。
“InputResource”也不应该有 ID/主键

我认为上述方法更简洁，但这取决于您的需求。
如果您想使用“AddOrUpdate”，我仍然认为添加 State 不是一个好主意。
您可以检查 Id 属性，如果已设置，则为 Update ，否则为 Add

*当然，我说的是您的公共 API。
在内部，在您的服务器（BusinessLayer-DataLayer）上，您可能有一个根据状态处理项目的解决方案，但我认为您不会考虑这个

【讨论】：