大家好。
在 c# .net VS 2008 中，我正在开发一个 N 层 CRM 框架解决方案，完成后我想分享它。
该架构基于：
数据访问层、实体框架、业务逻辑层、WCF，最后是表示层（win forms）。
在某处我读到，超过 2 层是有问题的，因为乐观并发更新（具有相同数据的多个客户端事务）。
在最大。2 层解决方案这应该不是问题，因为控件（如 datagridview）自己解决了这个问题，所以我问自己使用 2 层是否更好，从而避免乐观并发问题？
实际上，我想为大型项目而不是 2 层制作 N 层解决方案。我不知道如何解决这样的并发问题，希望在这里得到帮助。
当然应该有一些很好的机制来解决这个问题......也许有任何建议、例子等？
感谢你在期待。
最好的问候， Jooj
这不是层数的问题。问题是您的数据访问逻辑如何处理并发性。无论您有多少层，都应该在处理您的数据访问的任何层中处理并发。但我了解您来自哪里，因为 .NET 控件和组件可以隐藏此功能并减少所需的层数。
有两种常见的乐观并发解决方法。
第一种是在行上使用时间戳来确定用户在开始编辑时正在查看的版本在他们提交编辑时是否已被修改。请记住，这不一定是正确的 Timestamp 数据库数据类型。不同的系统将使用不同的数据类型，每种数据类型都有自己的优点和缺点。这是一种更简单的方法，适用于大多数设计良好的数据库。
第二种常见的方法是，在提交更改时，不仅通过 id 还通过用户更改的字段的所有原始值来识别有问题的行。如果字段和 id 的原始值与正在编辑的记录不匹配，则您知道这些字段中至少有一个已被其他用户更改。此选项的好处是，即使两个用户编辑相同的记录，只要他们不更改相同的字段，提交也会起作用。不利的一面是，就业务规则而言，可能需要进行额外的工作来保证数据库记录中的数据处于一致状态。
这是关于如何在 EF 中实现简单乐观并发的一个不错的解释。
我们使用组合手动合并（确定更改集和冲突），最后一个人根据数据要求获胜。如果数据更改与从公共原始值更改的相同字段发生冲突，则会引发合并类型异常并由客户端处理。
我想到了几件事：
1) 如果您使用的是 EF，那么您肯定没有数据访问层吗？！你的意思是数据库本身？
2）分层问题既是物理问题又是逻辑问题。所以你的意思是物理的还是逻辑的？
3）在任何分层的应用程序中都存在并发问题。即使在客户端-服务器中，人们也可以打开一个表单，去某个地方，然后在其他地方更改数据时返回，然后保存。您可以在保存时使用时间戳进行检查，以确保您上次更新是在您拥有数据时。
4) 不要对更少或更多的层次考虑太多。只需尽可能简单地实现功能并使用最少的层数。