仅使用存储过程通过合并复制访问数据库是否有优势？答案

【问题标题】：Are there advantages to only use stored procedures to access a database with merge replication?仅使用存储过程通过合并复制访问数据库是否有优势？
【发布时间】：2011-10-11 10:49:23
【问题描述】：

我有一个项目，其中 SP 是应用程序用来访问或修改 Sql Server 2008 数据库的唯一方式。我有开发人员要求放弃仅使用 SP 的方法，让他们直接在 DB 上使用 Linq to Sql。我必须决定是否允许这样做。我必须添加另一条信息，该项目正在增长，在不久的将来我们可能需要第二台具有合并复制功能的 Sql server 机器。

我之所以这么说是因为我相信（但我现在在 Internet 上找不到对此的任何支持）仅使用 SP 方法在合并复制方案中是有益的，因为这将避免冲突并带来更好的性能。

这个说法有任何道理吗？您能否链接到证明或反驳该陈述的参考文献？你有什么意见？

这已成为做出决定的决定性因素。

【问题讨论】：

围绕数据访问使用了哪些模式？即，如果您使用存储库模式来保护您的应用程序免受数据访问细节的影响，那么您可能不用担心，因为您知道可以用 anything 替换存储库，无论是 Linq to Sql，普通的旧 ADO.NET 或 ORM。
目前在数据访问层中没有好的可插拔模式。但是，添加到此遗留代码中的所有新代码都将开始实现接口，只是为了允许您提到的内容。但是，从 SP 更改为其他解决方案总是需要做很多工作，所以我现在想做出正确的决定。如果在具有合并复制的数据库中拥有仅 SP 系统有任何优点或缺点，您是否有任何信息？

标签： sql-server-2008 stored-procedures replication merge-replication

【解决方案1】：

我不认为存储过程或任何其他更改数据的方法确实是合并复制中的一个因素，因为进行更新不会直接触发将更改推送到分发数据库中。

例如，如果通过存储过程或通过Linq to Sql编辑行，则更改跟踪、合并和发布是相同的。

有一个关于potential for concurrency issues的问题，建议测试一下这个场景。

如果您使用的是 Linq to SQL，则需要 make sure you understand when a statement will be executed - 这并不特定于合并复制。

我的最后一点是照顾那些为了改变而改变的开发者。 Linq to SQL 将为您的特定应用程序带来什么好处？在您选择 Linq to SQL 之前，您还查看了哪些其他数据访问解决方案。

仅仅因为 Linq to SQL 对某些应用程序非常有用，并不意味着它对每个应用程序都是完美的，我认为这应该会影响您的决定。

就您个人而言，我会保留存储过程，直到您完全隔离数据访问 - 这是现阶段更重要的任务。

【讨论】：