2

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

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

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

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

4

7 回答 7

3

在其他答案中，我强烈建议在Database Project中将这些存储过程纳入源代码控制。然后，您可以使用源代码控制系统的功能来做几件事：

  1. 锁定某些代码，使其无法更改
  2. 如果代码更改，请通知您
  3. 如果存储过程的更改会阻止它们被调用，则警告您
  4. 对存储过程进行分支，以便每个团队可以拥有自己的更改代码版本，同时保持未更改的存储过程通用。您当然需要分离数据库中的不同版本。
于 2013-07-02T17:05:28.930 回答
2

我同意此线程上的其他发帖者的观点，即您不应该在不同的 .NET DLL 之间共享存储过程，这只是灾难的根源。如果您对数据库模式做任何复杂的事情，我也会回避 ORM 之类的实体框架，因为 ORM 擅长将简单的对象模型从您的 .NET 应用程序类转换为 SQL 表和 SP，但传统上在优化方面做得很差它们用于数据库端的性能。会有人提出不同的主张，如果你是一个专家，他们可能有一个正确的观点，可以像他们一样让 ORM 做你想做的事情，但你很可能不是，从长远来看，这会让你头疼。

共享数据访问层可能会起作用，但从概念上讲，您只是将依赖项的实现从 DBA 编写的一些代码更改为 .NET 程序员编写的一些代码。是的，您可以使用集成测试来获得更好的可验证性，但是使用 Red Gate 的 SQL 测试之类的工具可以为 SQL 提供相同的案例。如果这两个应用程序已经因共享 SP 而感到痛苦，我会回避这种方法。这表明应该消除依赖关系。

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

于 2013-07-02T16:38:04.733 回答
1

Depending on the owner of the DAL project, you could host web services and share the API. That way, you separate the Data Access Layer from the business logic, which allows anyone to use the same DAL without having to publish it to each different location.

From my point of view, it looks like both Team A and Team B should share the same core model and look at Multitier architecture as a possible solution.

于 2013-07-08T19:38:00.687 回答
1

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

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

其中的分区概念与域驱动设计中的有界上下文有关：

任何大型项目都在使用多种模型。然而，当组合基于不同模型的代码时，软件会变得有缺陷、不可靠且难以理解。团队成员之间的沟通变得混乱。通常不清楚在什么情况下不应该应用模型。

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

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

结合以上内容再次分析问题。考虑一下你是否遗漏了一些明确的上下文，这个通用功能应该存在。

于 2013-07-01T21:09:53.593 回答
1

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

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

此外，强烈建议在两个团队之间进行良好的沟通。

于 2013-07-06T23:43:16.313 回答
0

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

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

于 2013-06-27T03:12:33.047 回答
0

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

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

在 .NET 环境中实现此目的的一种合理机制是使用 Microsoft 的WebAPI。

简而言之，“我们如何共享一个存储过程？”的问题。很可能是在查看错误的抽象级别。

于 2013-07-08T15:12:45.847 回答