我正在保护在 MS SQL 之上运行的 ASP.NET/MVC Web 应用程序。作为其中的一部分，我有不同的数据库连接来在网站上执行不同的事情。
编辑 - 当然，由 DBA 和 Ops 人员来决定如何访问数据以及如何托管应用程序，但是对于一个不够精细的应用程序，他们无能为力，无法为他们提供所需的控制把事情锁起来。
系统只使用存储过程，没有动态 SQL。一些存储过程会改变数据，因此我将它们称为使用概念上不同的连接，而不是用于仅读取的其他数据访问的连接。SQL 用户无权访问存储过程以外的任何其他数据库对象。帐户授权具有单独的连接。Web 应用程序的某些部分显示计费信息，网站的其他部分直接计费工作。似乎有办法将隔板放置到位，将概念上不同的东西分开。
我正在寻找一种集成测试的方法，我对所选择的特权并不过分慷慨。如果开发人员试图在代码中的错误位置使用错误的访问级别，我想要一种在构建服务器上引发异常的机制，即使错误是所选帐户实际上具有太多权限，这不会给出来自数据库的错误。
我一直在创建 IDbCommand 的实现，该实现将充当 IDbCommand 实例的工厂，基本上将使用两个不同的连接向后端发出相同的命令，这些连接使用在 SQL Server 中具有不同访问权限的不同主体，然后抛出 if较低的特权就足够了。
这种方法有两个问题
- 它几乎没有“优雅”或明显完美无瑕。我几乎没有考虑过它，它已经有很多代码了。我必须将所有发生在较低连接上的事情排队，然后在较高特权的连接上重播，这在它的工作方式上是不现实的，并且可能会导致其他代码出现奇怪的计时问题。我喜欢编写代码，但我也希望我的测试值得信赖且易于理解，并且不会引入一组新的复杂性，这些复杂性会使测试以与被测代码不同的方式变得脆弱。也许如果我完全复制所有工作和所有数据并运行单独的数据库，那么构建服务器脚本将是一场噩梦。
- 它几乎不能称为颗粒状。
当然，这是一个解决了的问题，只是因为运气不好或谷歌 fu 才避开了我几个小时的搜索？