跨多个应用共享存储过程

Question

Team A有一个企业应用程序，它使用ADO.NET进行数据访问，执行存储过程。数据访问封装在它自己的项目中（让我们称之为DAL.dll）

B团队正在创建另一个不相关的应用程序，该应用程序正在重用企业应用程序中的存储过程。此应用程序当前正在使用MS应用程序块进行数据访问。我们遇到的问题是，无论何时Team A对存储过程中的输入/输出参数进行任何更改，Team B的应用程序中都会出现运行时错误，并且需要更新此应用程序以适应其他参数（或者是去除）。因此，在用户抱怨之前，大部分内容都不会引起注意。至少，我们希望应用程序抛出一个编译错误，以便构建过程警告我们所做的更改。

执行此操作的一种方法是让B团队的项目添加对DAL.dll的引用

我想知道是否还有其他更清洁的方法可以解决这个问题。如有必要，我们准备替换B组的MS数据应用程序块以使用不同的技术（实体框架？）。

Answer 1

在其他答案中，我强烈建议在Database Project中将这些存储过程放入源代码管理中。然后，您可以使用源代码管理系统的功能来执行以下操作：

1. 锁定部分代码，以便无法更改
2. 如果代码 已更改
，则会通知您
3. 如果存储过程以阻止调用它们的方式更改
，则向您发出警告
4. 对存储过程进行分支，以便每个团队都可以拥有自己的已更改代码版本，同时保持常见的未更改存储过程。您当然需要将数据库中的不同版本分开。

Answer 2

我同意这个帖子上的其他海报，你不应该在不同的.NET DLL中共享存储过程，这只是灾难的一个方法。如果您正在做任何复杂的数据库模式，我也会回避ORM的实体框架，因为ORM擅长将一个简单的对象模型从.NET应用程序类转换为SQL表和SP，但传统上在优化方面表现不佳它们用于数据库方面的性能。会有人声称不是这样，如果你是专家来讨论你想要的ORM，他们可能会有一个有效的观点，但是你可能不会这样做，从长远来看会让你头疼。

共享数据访问层可能有效，但从概念上讲，您只是将依赖项的实现从DBA编写的某些代码更改为.NET程序员编写的某些代码。是的，您可以使用集成测试来获得更好的可验证性，但是使用Red Gate的SQL Test等工具可以为SQL做同样的情况。如果两个应用程序已经因共享SP而遭受某种痛苦，我会回避这种方法。这表明依赖性应该被废除。

如果由我自己决定，我会为Team B的应用程序制作一个新架构。您可以在此处阅读有关SQL Server中模式的更多信息：MSDN Schema description for 2008 R2。您可以将它们视为SQL Server的命名空间，但需要一些额外的功能和访问控制等功能。在不同的共享数据库中将不同的应用程序分离为单独的模式可能会从长远来看实现最灵活的实现。

Answer 3

  

无关的应用程序正在重用企业应用程序中的存储过程

如果这两个应用程序真的无关，为什么这些共享程序甚至是同一个数据库。我知道这是一个很长的阅读，但我建议你阅读：A Better Path to Enterprise Architectures

那里的分配概念与bounded context in Domain driven design：

有关

  

任何大型项目都有多种型号可供使用。然而，当基于不同模型的代码被组合时，软件变得越来越不可靠，不可靠并且难以理解。团队成员之间的沟通变得令人困惑。通常不清楚在什么情况下不应该使用模型。

     

因此：明确定义模型适用的上下文。根据团队组织，应用程序特定部分的使用情况以及代码库和数据库模式等物理表现形式明确设置边界。保持模型在这些范围内严格一致，但不要被外界的问题分心或混淆。

当你没有明确地处理这个问题时，预计你会遇到问题。你很幸运，你看到了早期的失败，因为从长远来看它可能会变成更难找到的问题。

考虑到上述情况再次分析问题。考虑一下你是否遗漏了这个常见功能应该存在的明确背景。

Answer 4

我的问题是：哪个团队拥有存储过程并且数据库共享？通常作为一个好的架构/设计，你不应该有两个不同的应用程序共享相同的数据库/程序。

在两个不同的应用程序之间共享数据/功能的更好方法是通过服务或API，因此拥有该功能的团队将负责维护它。

此外，强烈建议两队之间保持良好的沟通。

Answer 5

根据DAL项目的所有者，您可以托管Web服务并共享API。这样，您就可以将数据访问层与业务逻辑分开，这样任何人都可以使用相同的DAL而无需将其发布到每个不同的位置。

从我的观点来看，看起来A队和B队应该共享相同的核心模型，并将Multitier架构视为一种可能的解决方案。

Answer 6

听起来创建两个应用程序可以共享的共享DAL是有意义的。

我会添加单元测试（或真正的集成测试）以确保DA​​L在更改后与应用程序兼容。这样，如果进行了不兼容的更改，您的测试将失败

Answer 7

“我想知道是否有其他更清洁的方法来解决这个问题。”

最简单的方法是让B队与A队坐下来，将相关的业务逻辑封装到共享API中。如何实现该API并不重要;重要的是API的界面被记录和版本化，以便每个人都知道会发生什么。

.NET环境中的一种合理机制是使用Microsoft的WebAPI。

简而言之，问题是“我们如何共享存储过程？”最有可能看到错误的抽象层次。