企业解决方案中的实体框架

Question

我今天向我们的治理委员会提供了服务。他们对实体框架（特别是数据团队负责人）有一些担忧。

他们有两个主要问题：

1. 由于EF动态生成SQL，因此可以使用SQL注入攻击（通过WCF服务和WCF数据服务使用时）。
2. EF会扩展以支持高负载情况而不会成为路径中的“慢点”吗？

我相当确定＃1。如果EF对SQL注入攻击持开放态度，我想我会听说过它。）但我希望MS能够说来自数据合同的输入是sanitized。 （有点像存储过程（在sproc中不使用动态SQL）。）

至于＃2我不确定。当我开始对基于EF的服务进行大量点击时，EF会让我感到悲伤吗？

Answer 1

1. 与使用手动编写的SQL相比，使用EF注入SQL的可能性更小。
2. 对此没有简单的答案。 “高负荷情况”太模糊，不能简洁地回答。一般来说，规模越大，任何“一个尺寸适合所有”解决方案的工作量就越少。一如既往，测量两次，切一次。

Answer 2

我同意克雷格的观点。他们信任手工编写的SQL，而不是微软这样的大工具生成的SQL吗？说实话，除非EF中有一个奇怪的错误，否则不可能进行SQL注入，因为EF总是生成参数化查询。换句话说，他们的论点是公牛。

对于＃2而言，EF不会是慢点，它将永远是您的数据库，因为您可以使用EF将您的Web服务扩展到多个服务器，大多数时间没有太多问题。然而，缩小数据库是一个完全不同的球类游戏。但是，我必须说O / RM可以轻松生成有时很难调整的“次优”SQL查询。 DBA对此并不总是满意。但是，根据我的经验，几乎总是可以调整这些SQL查询（通过重写LINQ查询）。在过去的几个月里，我已经做了很多，有时候可能会非常具有挑战性。在极少数情况下，您无法在.NET端进行足够的优化，您可以始终回退到索引视图，存储过程或手动SQL，但这种情况应该很少见。

Answer 3

只需运行探查器并检查EF产生的查询。您将看到参数化查询，它们是针对SQL注入的主要防御。因此没有EF不会对注入攻击开放，但如果您使用EntitySQL并手动连接字符串，则可能会对更高层进行注入攻击。

确保EF具有性能成本。这是简单快速开发的权衡，开发人员不需要太多关于构建应用程序的内部流程/技术的知识（在许多MS工具的情况下，钻孔的猴子可以构建应用程序，但性能和其他质量测量将足够了。

实际上，这些性能成本可能非常高，而且性能测试的重点是找出是否存在性能瓶颈。如果您发现部件太慢，则需要对其进行优化。它可以导致代码重构或创建存储过程来处理复杂查询。

对于DataServices，这可能更复杂。客户端可以触发一些复杂的查询，这将只需要很长时间，您无法控制该查询。对此的一些防御是限制服务级别上返回/查询的记录的数量。如果用户想要更多记录，他必须指定更详细的搜索条件。

Answer 4

对于＃2，每当引入抽象时，其将与性能进行权衡。只要它对您有意义，只能通过您的情况下的性能测试和分析来确定。阅读这篇文章，了解为什么SO需要自定义ORM Dapper才能给您一个想法。 Dapper还有一个performance test suite，您可以使用它来确定EF对典型查询的影响程度。

还有一个＃3。 EF的某些功能仍然不受支持，这可能会限制您的设计。例如<{3}}尚不支持。

EF仍在不断发展，并密切关注Unique Key constraints