数据库权限和ORMs

我最近一直在使用.NET的实体框架，绝对不想再使用存储过程。但是，我感到震惊的是，我为其构建此项目的公司有一项政策，即应用程序只被授予只有访问存储过程权限的帐户

显然，他们认为允许应用程序直接访问表/视图存在安全风险。我不明白

我的第一个问题是，是否有人能告诉我，直接访问数据库的应用程序可能会带来什么样的安全风险？及

如果是这样的话，有没有其他的ORM解决方案可以提供一个解决方案（我想不出任何atm的逻辑可能性），让我绕过对分配给我的用户帐户的限制？或者我对表和视图需要直接权限的理解是错误的

---

愚蠢的有限思维——除非他们将完整的访问逻辑放入数据库

---

对为什么安全不是理由有很好的解释。正如我所说的——除非完整的业务逻辑验证谁能看到数据库中的内容。。。。这就不再是一个多层应用程序了。

在特定的上下文中，限制对存储过程的访问非常有意义。这些过程公开API并处理处理（例如检查复杂约束），这在理论上是正确的。 没有简单的方法来声明跨列约束，比如“如果列A为null，那么列B应该是{X，Y，Z}中的一个”。多个应用程序可能正在使用过程API，并且所有应用程序都可以从这些过程中受益，从而确保以正确的方式处理数据

然而，任何试图在数据库中编写大量逻辑和在通用OOP语言中编写大量逻辑的人都知道，前者往往会导致无法维护、数据库锁定的无法理解的代码堆积如山，而后者通常被认为是“编写复杂应用程序/系统的方式”

虽然存储过程API方法远未消亡，但看到一个新项目开始使用这种模式，我真的会感到惊讶。ORMs远非完美，但它们确实提供了巨大的好处，这一点越来越被认为是理所当然的：整个应用程序可以用一种语言编写（Python、Java、Groovy、Ruby…），通常您可以在几分钟内切换DBMS（这非常有效，例如，当您在hsqldb上运行测试时，但在生产中使用postgresql），从数据库到数据库的数据打包要简单得多（ORM通常返回域对象，而不是原语），还有缓存优势等

---

有鉴于此，应用程序完全可以对其数据库中的所有内容进行CRUD访问。另外，如果您有一个只允许调用存储过程的帐户，我不建议您花时间研究如何规避访问权限：更好地利用您的时间是争取CRUD表访问权限。

我也这么想。我想不出一个合理的理由来解释为什么我的应用程序不能访问这些表。没有这样的业务逻辑来验证谁在数据库中看到了您所说的内容，那么它就毫无意义了。对于插入/更新，我们可以随心所欲地谈论它，但对于查询来说，纯SQL的灵活性是难以匹敌的。LINQ最终允许在编程语言中以本机方式公开它。放弃这一点——没有任何回报——是明显愚蠢的表现。有点苛刻，我仍然想试着理解这一推理背后是否有充分的理由，但我完全同意你的观点。我不希望每个程序功能都使用两种不同的语言，事实上并不苛刻。有很好的理由反对直接表访问，但它们大多可以通过视图来解决，这意味着您必须在数据库中使用过滤器逻辑。如果不是这样的话，在安全方面什么也得不到，在发展速度方面（即金钱），也会损失很多。不赚钱而丢钱通常被认为是愚蠢的；）考虑到sps所浪费的所有时间（也许对于那些精通sps的人来说可以更好地管理，但我却不行）。多个具有跨列约束的应用程序是否会从实施SOA中受益，而不是将进程存储在后端？在“看到一个新项目开始使用这种模式，我真的会感到惊讶”，然后你会感到震惊和非常失望，因为我希望我们的团队只使用ORM而不是传统的存储过程（以及IMO可疑的ApplicationBlocks.SqlHelper）跨列！=交叉表@Jonn我不确定我们是否站在同一个角度，但我可以说是的，我同意你的观点，在你描述的环境中，SOA比存储过程更好。@TomTom不确定你的意思。我的示例是交叉列约束。对于跨表约束和其他许多约束也是如此。同样，我认为它适用于列或表。不管怎样，您不在同一页面Tomislav是什么意思？您有权更改存储过程吗？存储过程是否具有对表的完全访问权限？ORM最适合于表，但是一个好的ORM通常会以一种相当糟糕的方式使用存储过程。我还没有探讨过这个选择。