如何解决 c# .NET N 层应用程序中的乐观并发更新？
大家好。
在 c# .net VS 2008 中，我正在开发一个 N 层 CRM 框架解决方案，当它完成后我想分享它。
该架构基于：
数据访问层、实体框架、业务逻辑层、WCF 以及最后的表示层（win 表单）。
我在某处读到，由于乐观并发更新（具有相同数据的多个客户端事务），超过 2 层是有问题的。
最大。 2 层解决方案这不应该成为问题，因为控件（如 datagridview）自己解决了这个问题，所以我问自己使用 2 层层是否不是更好，因此避免乐观并发问题？
实际上我想为大型项目制作一个 N 层解决方案，而不是 2 层。我不知道如何解决这样的并发问题，希望在这里得到帮助。
当然应该有一些好的机制来解决这个问题......也许有什么建议、例子等？
在期待中感谢您。
此致， 乔吉
Hy everyone.
In c# .net VS 2008 I'm developing an N-tier CRM framework solution and when it's done I want to share it.
The architecture is based on:
Data Access Layer, Entity Framework, Bussines Logic Layer, WCF and finally the presentation layer (win forms).
Somewhere I had read, that more than 2 tier layers are problematic, beacuse of the Optimistic Concurrency Updates (multiple client transactions with the same data).
In max. 2-tier layer solutions this should not be a problem because of the controls (like datagridview) that are solving this problem by themself, so I'm asking myself if it's not better to work with 2-tier layers and so avoid the optimistic concurrency problem?
Actually I want to make an N-tier layer solution for huge projects and not 2-tiers. I don't know how to solve concurrency problems like this and hope to get help right here.
Certainly there should be good some mechanisms to solve this... maybe any suggestions, examples, etc.?
Thanking you in anticipation.
Best regards,
Jooj
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这实际上不是层数的问题。问题是您的数据访问逻辑如何处理并发性。处理并发性应该发生在处理数据访问的任何层中，无论您有多少层。但我明白您的想法，因为 .NET 控件和组件可以隐藏此功能并减少所需的层数。
乐观并发解决的常见方法有两种。
第一个是在行上使用时间戳来确定用户开始编辑时查看的版本在提交编辑时是否已被修改。请记住，这不一定是正确的时间戳数据库数据类型。不同的系统将使用不同的数据类型，每种数据类型都有自己的优点和缺点。这是更简单的方法，并且适用于大多数设计良好的数据库。
第二种常见方法是，在提交更改时，不仅通过 id 还通过用户更改的字段的所有原始值来标识有问题的行。如果字段和 ID 的原始值与正在编辑的记录不匹配，您就知道至少其中一个字段已被另一用户更改。此选项的好处是，即使两个用户编辑相同的记录，只要他们不更改相同的字段，提交就会起作用。缺点是可能需要额外的工作来保证数据库记录中的数据在业务规则方面处于一致状态。
这里很好地解释了如何在 EF 中实现简单的乐观并发。
It's not really a question of the number of tiers. The question is how does your data access logic deal with concurrency. Dealing with concurrency should happen in whichever tier handles your data access regardless of how many tiers you have. But I understand where you're coming from as the .NET controls and components can hide this functionality and reduce the number of tiers needed.
There are two common methods of optimistic concurrency resolution.
The first is using a timestamp on rows to determine if the version the user was looking at when they started their edit has been modified by the time they commit their edit. Keep in mind that this is not necessarily a proper Timestamp database data type. Different systems will use different data types each with their own benefits and drawbacks. This is the simpler approach and works fine with most well designed databases.
The second common approach is, when committing changes, to identify the row in question not only by id but by all of the original values for the fields that the user changed. If the original values of the fields and id don't match on the record being edited you know that at least one of those fields has been changed by another user. This option has the benefit that even if two users edit the same record, as long as they don't change the same fields, the commit works. The downside is that there is possible extra work involved to guarantee that the data in the database record is in a consistent state as far as business rules are concerned.
Here's a decent explanation of how to implement simple optimistic concurrency in EF.
我们使用组合手动合并（确定更改集和冲突），最后一个获胜者取决于数据要求。如果数据更改与从公共原始值更改的相同字段发生冲突，则抛出合并类型异常并由客户端处理。
We use a combination manual merging (determining change sets and collisions) and last man wins depending on the data requirements. if the data changes collide same field changed from the a common original value then merge type exceptions are thrown and the clients handle that.
我想到了一些事情：
1）如果您使用 EF，那么您肯定没有数据访问层吗？！你是指数据库本身吗？
2）层次问题既是物理问题，又是逻辑问题。那么你的意思是物理的还是逻辑的？
3）在任何分层应用程序中都存在并发问题。即使在客户端-服务器中，人们也可以打开一个表单，去某个地方然后回来，然后在数据被其他人更改时保存。您可以在保存时使用时间戳进行检查，确保上次更新是在您拥有数据时。
4）不要在少或多的层次上考虑太多。只需尽可能简单并使用最少的层数来实现功能即可。
A few things come to my mind:
1) If you are using EF surely you don'y have Data Access Layer?! Do you mean database itself?
2) Question with tiers is both a phydical and logical one. So do you mean physical or logical?
3) In any-tiered application there is this issue with concurrency. Even in client-server, people could open a form, go soemwhere and come back and then save while the data has been changed by soemone else. You can use a timestamp to check while saving making sure your last update was when you have had the data.
4) Do not think too much on less or more tiers. Just implement the functionality as simple as possible and with the minimum number of layers.