Asp.net 跨多个应用程序共享存储过程

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

DAL.dll

）

---

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

一种方法是让团队B的项目添加对

DAL.dll的引用

我想知道是否有其他更干净的方法来解决这个问题。如有必要，我们准备替换团队B的MS数据应用程序块，以使用不同的技术（实体框架？）。
听起来创建两个应用程序都可以共享的共享DAL是有意义的

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

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

如果这两个应用程序真的不相关，为什么它们共享过程甚至是同一个数据库。我知道这是一本很长的书，但我建议您阅读以下内容：

其中的分区概念涉及：

在任何大型项目中都有多个模型。然而，当基于不同模型的代码组合在一起时，软件就会出现错误、不可靠和难以理解。团队成员之间的沟通变得混乱。在什么情况下不应该应用模型通常是不清楚的

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

如果你不明确地处理这个问题，你就会以问题告终。幸运的是，你看到了早期的失败，因为从长远来看，它会变成更难发现的问题

考虑到上述情况，再次分析问题。如果你错过了一些明确的上下文，这个公共功能应该生存。
 < P>我同意在这个线程上的其他海报，你不应该在不同的.NET DLL上共享存储过程，这只是一个灾难的处方。如果您要对数据库模式进行任何复杂的操作，我也会避开类似于ORM的实体框架，因为ORM擅长将简单的对象模型从.NET应用程序类转换为SQL表和SP，但传统上在数据库端的性能优化方面做得很差。会有人提出相反的观点，如果你是一名专家，能说服ORM做你想做的事情，他们可能会有一个合理的观点，但很可能你不是，从长远来看，这会让你头疼

共享数据访问层可能会工作，但从概念上讲，您只是将依赖关系的实现从DBA编写的一些代码更改为.NET程序员编写的一些代码。是的，您可以使用集成测试来实现更好的可验证性，但是可以使用诸如RedGate的SQL测试之类的工具对SQL进行同样的测试。如果这两个应用程序在共享SP时已经经历了某种痛苦，我会避开这种方法。这表明依赖性应该被消除

如果由我决定，我会为B组的应用程序创建一个新的模式。您可以在此处阅读有关SQL Server中架构的更多信息：。您可以将它们视为SQL Server的名称空间，但还需要一些额外的功能，如权限和访问控制。从长远来看，将不同的应用程序划分为同一共享数据库上的不同模式可能会带来最灵活的实现。
在其他答案中，我强烈建议将这些存储过程以一种简单的方式纳入源代码管理。然后，您可以使用源代码管理系统的功能来执行以下几项操作：

锁定部分代码，使其无法更改
如果代码发生更改，将通知您
如果存储过程的更改会阻止调用它们，请发出警告
分支存储过程，这样每个团队都可以拥有自己版本的更改代码，同时保持未更改的存储过程的通用性。当然，您需要在数据库中分离不同的版本
我的问题是：哪个团队拥有存储过程和共享数据库？通常，作为一个好的架构/设计，您不应该让两个不同的应用共享相同的数据库/过程

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

另外，强烈建议两个团队之间进行良好的沟通。
“我想知道是否有其他更干净的方法来解决这个问题。”

最干净的方法是团队B与团队A坐下来，将相关的业务逻辑封装到一个共享API中。如何实现API并不重要；重要的是API的接口是有文档记录和版本控制的，所以每个人都知道会发生什么

这方面的一个合理机制是