大家好。
在 c# .net VS 2008 中，我正在开发一个 N 层 CRM 框架解决方案，完成后我想分享它。
架构基于:
数据访问层、 Entity Framework 、业务逻辑层、WCF，最后是表示层(win 表单)。
我曾在某处读到，超过 2 层是有问题的，因为乐观并发更新(具有相同数据的多个客户端事务)。
在最大。 2 层解决方案这应该不是问题，因为控件(如 datagridview)自己解决了这个问题，所以我问自己使用 2 层是否更好，从而避免乐观并发问题？
实际上，我想为大型项目制作一个 N 层解决方案，而不是 2 层。我不知道如何解决这样的并发问题，希望能在这里得到帮助。
当然应该有一些很好的机制来解决这个问题......也许有什么建议、例子等？
谢谢你的期待。
最好的问候， 卓杰
最佳答案
这实际上不是层数的问题。问题是您的数据访问逻辑如何处理并发性。无论您有多少层，都应该在处理您的数据访问的任何层中处理并发。但我理解您的想法，因为 .NET 控件和组件可以隐藏此功能并减少所需的层数。
乐观并发解析有两种常见的方法。
第一个是在行上使用时间戳来确定用户在开始编辑时查看的版本在提交编辑时是否已被修改。请记住，这不一定是正确的时间戳数据库数据类型。不同的系统将使用不同的数据类型，每种类型都有自己的优点和缺点。这是更简单的方法，适用于大多数设计良好的数据库。
第二种常见方法是，在提交更改时，不仅通过 id，而且通过用户更改的字段的所有原始值来识别有问题的行。如果字段和 ID 的原始值与正在编辑的记录不匹配，您就知道至少有一个字段已被另一用户更改。此选项的好处是，即使两个用户编辑同一条记录，只要他们不更改相同的字段，提交就有效。缺点是可能需要额外的工作来保证数据库记录中的数据在业务规则方面处于一致状态。
Here's对如何在 EF 中实现简单的乐观并发的一个体面的解释。
关于c# - 如何解决 C# .NET N 层应用程序中的乐观并发更新？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3914305/