我想使用ORM，并且一直在关注EF 4.这个平台是否可扩展。我在网上看到很多东西，但是一切看起来都非常偏向于某种方式。任何人都知道基准或非主观信息。
在这一点上，EF是否会阻止SQL注入或XSS。我知道它使用了参数化查询，但这还够吗？
感谢任何帮助。
答案 0 :(得分：7)
好的，我在这里看到两个问题。
EF可扩展
回答非常困难（并且主观），但IMO是的。
以下是几个原因：
可伸缩性的主要实际好处是框架是如何在LINQ-to-Entities上构建的。当您编写查询时，您不是针对SQL Server或Oracle编写的，而是针对模型编写。根据您设置的提供程序（在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，狡猾的电子邮件等。与Entity Framework无关。使用HTML编码等方法在客户端完成XSS的预防。
答案 1 :(得分：1)
没有。 ORM并不是可扩展性的灵丹妙药。存在这样的事物，即物体和数据库的阻抗不匹配，已经存在多年。 ORMS试图通过提供魔术代码生成/映射解决方案来解决这个问题，这些解决方案可以提供仅使用对象的外观。
在具有许多客户端程序和单个/多个服务器方案的多层环境中，对于必须提交到数据库的每个更改，都需要执行检查以确保不会过度写入别人的更改数据，或尝试更新已删除的数据。这不是ORM引入的新问题，而是在N-Tier环境中更新数据库的整个时代出现过很多次。 ORMS没有解决这个问题。在某些情况下，如果ORM是数据库的单个条目，则ORM成为瓶颈。这意味着使用ORM创建可扩展的体系结构会产生问题，因为在ORM上执行数据库检查意味着如果您使用的N-Tier ORM解决方案中存在重复的ORM层，则可以通过更新异常检查。
由于上述原因，这就是我们使用存储过程的原因。但是，如果您使用存储过程，这会自然地模糊数据库的基础数据结构，那么这会增加对象和数据库实体的阻抗不匹配。关于使用存储过程和依赖表锁定/行摇摆的一件事，一些更新方案得到了解决，因为我们将瓶颈转移到底层数据库设计的性能。
答案是什么？不要将对象用于数据库。对象非常适合分析，在与RDBMS数据库交互时对代码设计不利。
如果您真正想到的SQL和RDBMS数据解决方案是一个问题，在某些情况下，请查看一些NOSQL解决方案。仍然不是解决所有问题的灵丹妙药，但在某些情况下，它们提供了比直接SQL解决方案更好的解决方案。
对象不是所有问题的答案。从代码中退一步，看看你想要做什么，并思考一个对象是否是正确的方法。
至于安全性，没有ORMS不会有助于安全。虽然它们确实有助于防止某些形式的注射攻击。