我正在开发一个 Sometimes Connected CRUD 应用程序，该应用程序主要供社会 worker 和护士团队 (2-4) 使用，以计划的形式跟踪患者信息。该应用程序是我之前创建的 ASP.Net 应用程序的重新可视化。 4 个数据库中大约有 200 个表。 Web 应用程序版本严重依赖 SP，但由于此版本是将指向本地数据库的 winform 应用程序，我认为没有理由继续使用 SP。另外值得注意的是，我曾计划使用 Merge Replication 来处理同步部分，但这两者似乎存在一些问题。
我正在尝试了解用于 DAL 的方法。我最初计划使用 LINQ to SQL，但我读过一些花絮，指出它在有时连接的设置中不起作用。因此，我一直在尝试阅读和试验许多解决方案； SubSonic、NHibernate、 Entity Framework 。这是一个相对简单的应用程序，并且由于“迫在眉睫”的 verion 3 重新设计，这项工作可能几乎是“一次性的”。这里的重点是尽快启动并运行桌面版本。
我在这里想问的是，任何有使用这些技术(或我没有列出的技术)经验的人都可以借给我你辛苦得来的智慧。在您看来，我最好的方法是什么？关于创建此类应用程序的任何其他见解？我真的很难处理这个程序的 DAL 部分。
谢谢!
最佳答案
如果存储过程执行您希望它们执行的操作，我不得不说我怀疑您是否会通过丢弃它们并重新实现它们来获得好处。此外，当需要将数据复制回主数据库时，使用存储过程或 LINQ to SQL 风格的数据访问并不重要，因此担心使用哪个 DAL 似乎是转移注意力。
关于有时连接的应用程序的棘手部分是想出一个好的冲突解决系统。我的建议:
- 始终使用 RowGuid 作为表的主键。如果您总是有唯一键控的新记录，则合并复制效果最好。
- 意识到合并复制的作用有限:它很棒可以将不同系统中的新数据整合在一起。它甚至可以计算出单方面的更新。它不能神奇地确定你的新记录和我的新记录实际上是一样的，也不能在没有人为干预或优先级规则的情况下真正处理双方的变化。
- 因此，您将需要“匹配”规则来解析声称是新的但实际上不是的记录。请注意，这是一个模糊的步骤:您很少能依靠一个唯一的 key 来实际输入完全相同的两边并且没有错误。这意味着在您的许多指标相同或相似的地方给予加权匹配。
- 用于解决冲突和将"new"记录与原始记录匹配的用户界面需要易于操作。我使用的东西看起来类似于许多源代码控制系统使用的经典三向合并:记录 A、记录 B、合并记录。他们可以通过单击标题按钮将合并记录默认为 A 或 B，也可以通过单击它们来选择每个字段。最后，合并记录字段开放供编辑，因为有时您需要从 A 和 B 获取地址的一部分。
这些都不应该对您的数据访问层产生丝毫影响:这都是比您的 DAL 更低级别(合并复制，由数据库本身提供)或更高级别(冲突解决，由您的业务规则提供的解决方案) .
关于c# - 有时连接 CRUD 应用程序 DAL，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/627687/