实体框架 4.0 扩展和安全性
我想使用 ORM，并且一直在关注 EF 4。这个平台是否可扩展。我在网上看到了很多东西，但一切看起来都非常有偏见。任何人都知道基准或非主观信息。
在这一点上，EF 是否可以防止 SQL 注入或 XSS。我知道它使用了参数化查询，但这足够了吗？
任何帮助表示赞赏。
I want to use an ORM, and have been looking at EF 4. Is this platform scalable. I see a lot of stuff on the web, but everything looks very biased in one way or the other. Anyone know of benchmarks or non-subjective information.
On that point, does EF prevent SQL injection or XSS. I know that it used parametrized queries, but is that enough?
Any help is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好的，我在这里看到两个问题。
很难（且主观）回答，但在我看来是的。
原因如下：
可扩展性的主要真正好处是框架如何构建在 LINQ-to-Entities 上。当您编写查询时，您不是针对 SQL Server 或 Oracle 进行编写，而是针对模型进行编写。根据您设置的提供程序（在 web.config 中），EF 会将这些模型查询转换为适当的 T-SQL（或 P-SQL）。
因此（理论上），您可以针对 SQL Server 编写代码，然后将 web.config 提供程序更改为 Oracle，并且您的代码应该可以工作。显然，Entity-SQL 的情况并非如此（因为您正在编写 T-SQL，而不是 LINQ）。
没有任何 ORM 工具能够真正“防止”SQL 注入攻击 - 它们只能为开发人员提供防止它的工具。
与使用参数化查询的经典 ADO.NET 一样，实体框架具有 Entity-SQL，它允许执行预先生成的 SQL、存储过程等。
在这种情况下，您需要使用参数化查询来防止 SQL 注入。对于大多数 EF 工作，您将使用 LINQ 编写查询，这要安全得多，因为它在成为 SQL 之前会经过许多阶段的处理。
XSS 在客户端通过注入 JavaScript、狡猾的电子邮件等方式被利用。与实体框架无关。 XSS 的预防是在客户端通过 HTML 编码等方式完成的。
Okay so i see two questions here.
Very difficult (and subjective) to answer, but IMO yes.
Here's a few reasons why:
The main real benefit in scalability is how the framework is built on LINQ-to-Entities. When you write queries, you are not writing against SQL Server or Oracle, you are writing against the Model. Depending on what Provider you have setup (in web.config), EF will translate these model queries into the appropriate T-SQL (or P-SQL).
Therefore (theoretically), you could write code against SQL Server, then change the web.config provider to Oracle, and your code should work. Obviously this isn't the case for Entity-SQL though (as you are writing T-SQL, not LINQ).
No ORM tool can really "prevent" SQL Injection attacks - they can only provide the developer with the tools to prevent it.
As with classic ADO.NET where you use parameterized queries, Entity Framework has Entity-SQL, which allows to to execute pre-generated SQL, stored procedures, etc.
In this scenario, you need to use parameterized queries to prevent SQL injection. For most EF work, you will be writing queries with LINQ, which is a lot safer because it gets hydrated through a lot of stages before it becomes SQL.
XSS is exploited on the client-side via things like injected JavaScript, dodgy emails, etc. Has nothing to do with Entity Framework. Prevention of XSS is done on the client-side with things like HTML encoding.
不。ORM 并不是可扩展性的灵丹妙药。有一种叫做对象和数据库的阻抗不匹配的现象，已经存在很多年了。 ORMS 试图通过提供神奇的代码生成/映射解决方案来解决这个问题，这些解决方案看起来就像只处理对象一样。
在具有许多客户端程序和单/多服务器场景的多层环境中，对于必须提交到数据库的每个更改，都需要执行检查以确保您不会在数据上重写其他人的更改，或尝试更新已删除的数据。这并不是 ORM 引入的新问题，而是在 N 层环境中更新数据库的整个过程中多次出现的问题。 ORMS 并不能解决这个问题。在某些情况下，如果 ORM 是数据库的单个条目，那么 ORM 就会成为瓶颈。这意味着使用 ORM 创建可扩展架构会出现问题，因为在 ORM 上执行数据库检查意味着如果您使用具有重复 ORM 层的 N 层 ORM 解决方案，则更新异常检查可能会被忽略。
由于上述原因，这就是我们使用存储过程的原因。但是，如果您使用存储过程，它自然会混淆数据库的底层数据结构，那么这会增加对象和数据库实体的阻抗不匹配。使用存储过程并依赖表锁定/行摇摆的一件事是，当我们将瓶颈转移到底层数据库设计的性能时，一些更新场景得到了解决。
那么答案是什么呢。不要将对象用于数据库。与 RDBMS 数据库交互时，对象非常适合分析，但不利于代码设计。
如果您真正思考的 SQL 和 RDBMS 数据解决方案存在问题（在某些情况下确实如此），请查看一些 NOSQL 解决方案。仍然不是解决所有问题的灵丹妙药，但在某些情况下它们提供了比直接 SQL 解决方案更好的解决方案。
对象并不能解决所有问题。从代码中退一步，看看您想要做什么，并思考对象是否是正确的方法。
至于安全性，没有 ORMS 无助于安全性。尽管它们确实有助于防止某些形式的注入攻击。
No. ORMs are not a panacea for scalability. There is such a things called the impedance mismatch of objects and databases which has been around for many years. ORMS try to solve this by providing magic code generation/mapping solutions that give the appearance of just working with objects.
In a multi-tier environment with many client programs and a single/many server scenario, for every change that has to be committed to the database, checks need to be performed to make sure that your not over writing someone elses change on the data, or trying to update data that has been removed. This is not a new problem introduced by ORMs but one which appears many many times throughout the ages of updating databases in N-Tier environments. ORMS do not solve this problem. In some cases, if the ORM is the single entry to the Database, the ORM becomes a bottle neck. This means that to create a scalable architecture using an ORM becomes problematic as having DB checks performed on the ORM means that the update anomaly checks could be by passed if your using an N-Tier ORM solution where you have duplicate ORM tiers.
For the reasons above, this is why we use stored procedures. But if your using stored procedures, which naturally obfuscate the underlying data structures of the database then this increases the impedance mismatch of objects and database entities. One thing about using stored procedures and relying on table locking/row rocking, some of the update scenarios are solved, as we shift the bottle neck to the performance of the underlying database design.
So whats the answer. Don't use objects for databases. Object are great for analysis, bad for code design when interacting with RDBMS databases.
If your really thinking SQL and RDBMS data solutions are a problem, which in some scenarios they are, take a look at some of the NOSQL solutions out there. Still not a panacea for all problems, but in some cases they provide a better solution than a straight SQL solution.
Objects are not the answer to all problems. Step back from your code, take a look at what your trying to do, and think if an object is the right approach.
As for security, no ORMS do not aid security. Although they do help prevent some forms of injection attacks.