Entity Framework 4.0 扩展性和安全性

Question

我想使用 ORM，并且一直在研究 EF 4。这个平台是否可扩展。我在网上看到了很多东西，但从某种角度来看，一切看起来都非常有偏见。任何人都知道基准或非主观信息。

在这一点上，EF 是否会阻止 SQL 注入或 XSS。我知道它使用了参数化查询，但这是否足够？

感谢任何帮助。

Answer 1

没有。 ORM 不是可扩展性的灵丹妙药。有一种东西叫做对象和数据库的阻抗不匹配，已经存在很多年了。 ORMS 试图通过提供神奇的代码生成/映射解决方案来解决这个问题，这些解决方案看起来就像是在处理对象。

在具有许多客户端程序和单/多服务器方案的多层环境中，对于必须提交到数据库的每个更改，都需要执行检查以确保您不会过度编写其他人的更改数据，或尝试更新已删除的数据。这不是 ORM 引入的新问题，而是在 N 层环境中更新数据库的整个时代多次出现的问题。 ORMS 不能解决这个问题。在某些情况下，如果 ORM 是数据库的单个条目，那么 ORM 就会成为瓶颈。这意味着使用 ORM 创建可扩展架构会成为问题，因为在 ORM 上执行数据库检查意味着如果您使用具有重复 ORM 层的 N 层 ORM 解决方案，则可以通过更新异常检查。

由于上述原因，这就是我们使用存储过程的原因。但是，如果您使用存储过程，这自然会混淆数据库的底层数据结构，那么这会增加对象和数据库实体的阻抗不匹配。使用存储过程和依赖表锁定/行摇摆的一件事，当我们将瓶颈转移到底层数据库设计的性能时，一些更新场景得到了解决。

所以答案是什么。不要将对象用于数据库。对象非常适合分析，在与 RDBMS 数据库交互时不利于代码设计。

如果您真正思考的 SQL 和 RDBMS 数据解决方案存在问题（在某些情况下确实存在问题），请查看现有的一些 NOSQL 解决方案。仍然不是解决所有问题的灵丹妙药，但在某些情况下，它们提供了比直接 SQL 解决方案更好的解决方案。

对象并不是所有问题的答案。从你的代码中退后一步，看看你想做什么，想想一个对象是否是正确的方法。

至于安全，没有 ORMS 无助于安全。尽管它们确实有助于防止某些形式的注入攻击。

Answer 2

好的，我在这里看到两个问题。

EF 可扩展

回答非常困难（且主观），但 IMO 是的。

原因如下：

• 使用通用查询语言 (LINQ)
• 允许多个提供程序（SqlServer、Oracle 等）
• 允许双向映射（代码优先、模型优先、数据库优先）
• 包括“经典 ADO.NET”支持（存储过程、Entity-SQL）

可扩展性的主要真正好处是该框架是如何构建在 LINQ-to-Entities 之上的。当您编写查询时，您不是针对 SQL Server 或 Oracle 编写，而是针对模型编写。根据您设置的 Provider（在 web.config 中），EF 会将这些模型查询转换为适当的 T-SQL（或 P-SQL）。

因此（理论上），您可以针对 SQL Server 编写代码，然后将 web.config 提供程序更改为 Oracle，您的代码应该可以工作。显然，Entity-SQL 不是这种情况（因为您正在编写 T-SQL，而不是 LINQ）。

EF 是否阻止 SQL 注入或 XSS

没有 ORM 工具可以真正“阻止”SQL 注入攻击 - 它们只能为开发人员提供工具来阻止它。

与使用参数化查询的经典 ADO.NET 一样，Entity Framework 具有 Entity-SQL，它允许执行预生成的 SQL、存储过程等。

在这种情况下，您需要使用参数化查询来防止 SQL 注入。对于大多数 EF 工作，您将使用 LINQ 编写查询，这要安全得多，因为它在变成 SQL 之前要经过很多阶段。

XSS 在客户端通过注入 JavaScript、狡猾的电子邮件等方式被利用。与实体框架无关。 XSS 的预防是在客户端通过 HTML 编码等方式完成的。