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