C# SQL Server存储过程与外部dll

我试图说服某人，使用外部DLL管理sql数据比使用存储过程更好。目前，与我一起工作的人正在使用vba并调用sql存储过程，以从许多不同的来源获取所需的复杂数据。据我所知，进行此类操作的最佳方法是使用dll/某个中间层来获取数据，并能够根据需要对其进行格式化

要记住的一些事情：

• 与我共事的人不太关心是否能够扩展到比我们现在更远的地方
• 他们不想切换到不同的平台
• 在当前的设置中，他们没有看到太多的性能问题
• 使用dll需要做更多不同方向的工作
• 如果现在这样做没有问题的话，他们不想改变。（所以，仅仅因为这不是正确的方法就行不通……我试过）

---

那么，有谁能告诉我使用外部dll然后再使用sql存储过程的一些好处吗？

我真的认为这可以归结为一个偏好问题。就我个人而言，我喜欢ORM&将查询保存在DLL中，而不是存储在进程中，我发现它们比将进程部署到数据库更容易维护和分发。但是，与原始查询相比，S.Proc有一些特定的优势。一些优化和一些服务器端逻辑可以在某些方面提高性能

总而言之，我个人更喜欢在代码中工作，而不是在DB mumbo jumbo中工作，所以这就是我选择DLL方法的真正原因

另外，您还可以将源代码保存在源代码管理中，使用存储过程要困难得多

---

就我的2c。

同意关于控制代码的观点，在DLL中要容易得多。源代码管理也是如此。然而，从纯性能的角度来看，存储过程终有一天会赢，因为它们是编译的，而不仅仅是缓存的。我不知道这是否会产生足够的不同，但我想我会把它扔进去

使用存储过程也可以更加安全，因为您可以只锁定对存储过程的访问，并且不必向任何有连接的人公开表数据

---

我想我不是在回答你的问题，而是在指出你论点中的漏洞。对此很抱歉，但我是从他们的角度来看的。

使用存储过程，编写数据访问层，通过单独dll中的参数化命令调用它们。存储过程是一种标准，给您带来了很多好处，参数化命令给您带来了自动字符串安全性

这种类型的设计基本上是标准化的，而且已经有很多年了，微软已经在.NET4中为您提供了一个框架来构建它

或多或少，你和另一个人都是对的，使用存储过程实现安全性，分离DAL实现安全性和可重用性，还有很多原因

ORM/DLL方法 Pro:

• 您不必学习SQL或存储过程语法

Con:

• 使单个事务中的多个操作复杂化
• 增加应用程序和数据库之间的行程的风险，这意味着数据同步/并发问题
• 在复杂的查询中完全失败；由于这一点，大多数支持通过ORM存储过程

---

您可以将SQL（包括存储过程）保存在平面文件中。文件扩展名可以是txt，但大多数使用sql-makes将sql源代码存储在CVS/etc模拟vs.NET或Java源代码中。

不得不说，我倾向于同意您同事的看法。如果您确信使用外部dll比使用存储过程更可取，那么您基于什么信念？到目前为止，你已经给出了一些极具争议性的论断，似乎在四处寻找更多的“证据”来支持你的观点。你“理解”的来源是什么？是否有实际需要关注缩放？您是否有实际的机会交换您的数据库？您的评论带有过早优化或宇航的味道。SQL Server Management studio（至少是较新版本）将连接到源代码管理系统，因此将SP源代码置于控制之下并不难。我们用setup&permissions语句包装直接sp源代码，并将其置于源代码控制之下。这真是一件不费吹灰之力的事。