… 也许，如果只有C#应用程序访问数据库。但假设多个用不同语言（和不同目的）编写的应用程序都需要访问数据库呢？你可以通过存储过程来实现，或者（根据我的经验更好）添加一个中间服务器进程，应用程序通过公开文档化的API来使用该进程，然后该进程再与数据库通信，而数据库可能通过存储过程为中间服务器提供访问。同样根据经验：例如，我和几位同事曾在一家大型投资银行工作过。底层数据库大多是供应商的专有数据库，或者是银行内其他团队编写的。这些数据库版本管理得很差（糟糕！）。我们编写了SQL查询/存储过程来访问VB（现在可能是C#）无法完成的数据（这会耗费巨大的精力）。然后我们为运行我们查询的服务器提供了COM接口。幸运的是，我们不需要提供更新，但同样的思路同样适用。这几乎可以完全隔离应用程序和数据库。…
源讨论当权衡过度时使用数据库的错误方式原帖 103 条评论 · 导入时统计据我所知，我曾经遇到过的最糟糕的代码库大量使用了存储过程。多年来，人们懒得或害怕去更新它们——这实际上是问题的根源。这导致了应用程序代码中各种疯狂的模式，比如在需要批量操作时却在循环中调用。或者把几个存储过程调用串在一起以达到预期结果，而实际上需要根据需求的变化来合并或分解它们。 如果你招聘开发人员是看中他们对C#的经验（这个应用程序是用C#编写的），那么你可能希望大部分业务逻辑用C#编写。甚至我目前公司的DBA们也倾向于只在最后不得已的情况下使用存储过程。 那个团队最终决定使用NoSQL数据库重写整个应用程序。我没有留下太久，所以没有看到结果。…
完整原文把你的经验，加入这段讨论。
> 也许，如果只有C#应用程序访问数据库。但假设多个用不同语言（和不同目的）编写的程序都需要访问数据库呢？ 我不想听起来像在人身攻击，但真令人作呕。 一个被多个应用程序访问的数据库，不管用的是多少种语言，都是一个很糟糕的信号。 如果我有一个用户数据库，而数百个其他应用程序都想使用其中的数据，它们都必须通过我的应用程序。我拥有这个数据库，我决定里面有什么数据，数据的结构如何，以及何时更改。 多个应用程序访问同一个数据库会带来官僚主义的噩梦——“App A想把名字字段改成UTF-8”——每个其他使用该数据库的程序都需要被通知（最好运气好能搞清楚还有哪些其他程序，以及谁拥有它们）。如果你想要说“那些其他程序应该…
完整原文> 你可以通过存储过程来实现，或者（根据我的经验更好）通过添加一个中间服务器进程，应用程序通过公开的API与之交互，然后该进程再与数据库通信，而数据库可能为中间服务器提供存储过程访问权限。 我不明白这和OP所说的有什么实质性的不同，你们都在倡导在数据库前放一个单独的服务器。我们可以称它为中间的或者不，但区别在于API是否公开，因此将业务逻辑保留在应用代码中是有意义的。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。