有时连接的CRUD应用程序数据访问层（DAL）

Question

我正在开发一个有时连接的CRUD应用程序，主要由2-4人的社工和护士团队使用，以计划的形式跟踪患者信息。该应用程序是ASP.Net应用程序的重新构想，而我加入之前已经创建了。该应用程序跨越4个数据库，大约有200个表。Web App版本严重依赖于SP's，但由于这个版本是指向本地数据库的winform应用程序，我认为没有继续使用SP's的理由。另外值得注意的是，我原计划使用Merge Replication来处理同步部分，但两者似乎存在一些问题。

我试图了解在DAL中使用哪种方法。我最初计划使用LINQ to SQL，但我读到过一些片段说明它在有时连接的设置中不起作用。因此，我一直在尝试阅读和实验许多解决方案；SubSonic，NHibernate，Entity Framework。这是一个相对简单的应用程序，并且由于“迫在眉睫”的第3版重设计划，这个努力可能会边缘化。重点在于尽快建立桌面版本。

我在这里询问任何有使用这些技术（或我未列出的技术）经验的人，借给我你们辛苦得来的智慧。在您的意见中，我最好的方法是什么？关于创建这种应用程序的任何其他见解？我真的在DAL部分努力。

谢谢！

- Mr_Mom

---

微软曾经在 .net 1.1 刚推出时展示过这种用例的技术演示。我想他们称之为断开的记录集。暂时没时间去谷歌，稍后我会再查一下。 - jason saldo

Answer 1

如果存储过程能够满足您的需求，我必须说我对于抛弃它们并重新实现持怀疑态度。此外，当需要将数据复制回主数据库时，使用存储过程或LINQ to SQL风格的数据访问似乎并不重要，所以担心使用哪种数据访问层似乎是一个红鲱鱼。

有时连接应用程序的棘手之处在于设计一个良好的冲突解决系统。我的建议：

• 始终使用RowGuids作为表的主键。如果您始终具有新记录的唯一键，则合并复制最有效。
• 请注意，合并复制只能做到这么多：它非常适合将来自不同系统的新数据组合在一起。它甚至可以解决单边更新的问题。但是，它无法神奇地确定您的新记录和我的新记录实际上是相同的，也无法真正处理双方的更改而不需要人工干预或优先规则。
• 因此，您需要“匹配”规则来解决声称是新的记录，但实际上并非如此的记录。请注意，这是模糊步骤：您很少能够依靠唯一键实际上在两侧完全相同并且没有错误地输入。这意味着给定权重匹配，其中许多指标相同或类似。
• 解决冲突并将“新”记录与原始记录匹配的用户界面需要易于操作。我使用的东西看起来类似于许多源代码控制系统使用的经典的三向合并：记录A、记录B、合并记录。他们可以通过单击标题按钮将合并的记录默认为A或B，并且还可以通过单击它们来选择每个字段。最后，合并记录字段是可以编辑的，因为有时您需要从A和B中获取地址的一部分。

这些都不应该对您的数据访问层产生任何影响：这些都是比您的 DAL 更低级别的操作（由数据库本身提供的合并复制），或者更高级别的操作（由您的解决方案提供的业务规则冲突解决）。

- Godeke

Answer 2

如果您可以在本地安装数据库系统，请选择您熟悉的系统。我认为最大的问题将是同步和合并部分。您必须考虑几种可能性：更改了服务器上其他人删除的内容。谁来决定？

我自己从未使用过同步框架，只是读了一篇文章。但这可能会为您提供一个坚实的基础。但是，无论您选择哪种数据访问方式，解决业务逻辑的方案可能会产生更广泛的影响...

- Sascha

Answer 3

微软在2004年发布了一个名为issueVision的示例应用程序。
http://windowsclient.net/downloads/folders/starterkits/entry1268.aspx

在joelonsoftware.com的旧帖子中找到了链接。 http://discuss.joelonsoftware.com/default.asp?joel.3.25830.10

其他想法...
移动宽带怎么样？明天就可以使用几张3G手机卡，您的应用程序将不需要更改，除非有大页面/图形。

在现场使用Excel电子表格。使用DTS或SSIS将数据导入应用程序。同时创建“更好”的解决方案。

祝你好运！

- jms

Answer 4

如果您所说的SP是存储过程，我不确定我理解您试图摆脱它们的原因。考虑到它们快速、经过验证并已经为您编写（即已测试），保留尽可能多的原始（工作）代码库对于制作模仿原始应用程序的应用程序肯定有明显的优点，其中最小的一个是速度。

我建议您安装本地数据库副本，然后在连接时将自上次连接以来受影响的所有记录推送到主数据库。

- SnOrfus