企业解决方案中的实体框架
我今天向我们的治理委员会介绍了我的服务。他们对实体框架（尤其是数据团队的负责人）有一些担忧。
他们主要担心两个问题：
- 由于 EF 会动态生成 SQL，因此它是否容易受到 SQL 注入攻击（当通过 WCF 服务和 WCF 数据服务使用时）。
- EF 是否会横向扩展以支持高负载情况，而不会成为路径中的“慢点”？
我相当确定#1。 ）如果 EF 对 SQL 注入攻击开放，我想我会听说过它。）但我会喜欢 MS 的一些东西，它说数据契约的输入是 已清理。 （有点像存储过程（在存储过程中不使用动态 SQL）。）
至于#2，我不确定。当我开始收到针对基于 EF 的服务的大量点击时，EF 会让我感到悲伤吗？
I pitched my service to our governance board today. They had some concerns about Entity Framework (especially the head of the data team).
Their were two main concerns:
- Since EF generates its SQL on the fly is it open to SQL Injection attacks (when used via WCF Services and WCF Data Services).
- Will EF Scale out to support high load situations without becoming the "slow spot" in the path?
I am fairly sure of #1. )If EF was open to SQL Injection attacks I think I would have heard about it.) But I would love something from MS that says the inputs from Data Contracts are sanitized. (Kind of like a stored procedure (that does not use Dynamic SQL in the sproc).)
As for #2 I am not sure. When I start getting high volume of hits against my EF based services, is EF going to cause me grief?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我同意克雷格的观点。他们更信任手写的 SQL，而不是 Microsoft 这么大的工具生成的 SQL？说实话，除非EF有奇怪的bug，否则不可能进行SQL注入，因为EF总是生成参数化查询。换句话说，他们的论点纯属无稽之谈。
对于#2，EF 不会是慢点，它始终是您的数据库，因为您可以使用 EF 将您的 Web 服务扩展到多个服务器，大多数时候不会出现太大问题。然而，横向扩展数据库是完全不同的事情。然而，我必须说，O/RM 可以轻松生成有时难以调整的“次优”SQL 查询。 DBA 并不总是对此感到满意。然而，根据我的经验，几乎总是可以调整这些 SQL 查询（通过重写 LINQ 查询）。在过去的几个月里我已经做了很多这样的事情，有时这可能相当具有挑战性。在极少数情况下，您无法在 .NET 方面进行足够的优化，您始终可以回退到索引视图、存储过程或手动 SQL，但这应该很少见。
I agree with Craig. They trust hand-written SQL more than SQL generated by such big tool from Microsoft? To be honest, unless there is a strange bug in EF, it is not possible to do SQL injection, because EF always generates parameterized queries. In other words, their argument is plain bullocks.
And for #2, EF will not be the slow spot, it will always be your database, because you can scale your web service with EF on it out to multiple servers, without much problem most of the time. Scaling out your database however is a completely different ball game. However, I must say that O/RMs can easily generate 'sub optimal' SQL queries that are sometimes hard to tune. DBAs will not always be happy with this. However, in my experience is it is almost always possible to tune those SQL queries (by rewriting the LINQ queries). I've done that a lot in the last few month and it can be quite challenging some times. In that rare case that you can't optimize on the .NET side enough, you can always fall back to an indexed view, stored procedure or manual SQL, but that should be rare.
只需运行探查器并检查 EF 生成的查询即可。您将看到参数化查询，这是针对 SQL 注入的主要防御措施。因此，没有 EF 不会受到注入攻击，但如果您使用 EntitySQL 并手动连接字符串，则可能会对更高层进行注入攻击。
当然 EF 有性能成本。这是简单和快速开发的权衡，开发人员不需要对内部流程/技术有太多了解来构建应用程序（在许多 MS 工具的情况下，熟练的猴子可以构建应用程序，但性能和其他质量测量将足够）。
实际上这些性能成本可能非常高，性能测试的重点是发现是否存在性能瓶颈。如果您发现某个部分太慢，则需要您对其进行优化。它可能导致代码重构或创建存储过程来处理复杂的查询。
对于数据服务，这可能会更复杂。客户端可以触发一些复杂的查询，这只会花费很长时间，并且您无法控制该查询。对此的一些防御措施是限制服务级别上返回/查询的记录的数量。如果用户想要更多记录，他必须指定更详细的搜索条件。
Just run the profiler and check what queries EF produces. You will see parametrized queries which are main defence against SQL injection. So no EF is not open to injection attacks but if you are using EntitySQL and concatenating strings manually you can have injection attack on higher layer.
Sure EF has performance costs. This is trade off of easy and rapid development where developers don't need to have too much knowledge about internal processes / technologies to build an application (in case of many MS tools a drilled monkey can build an application but performance and other quality measurements will be adequate).
Actually these performance costs can be very high and it is point of performance testing to find if there is performance bottleneck or not. If you find the part which is too slow it is up to you to optimize it. It can lead to code refactoring or creating stored procedures to handle complex queries.
In case of DataServices this can be more complex. Client can trigger some complex query which will simply take long and you don't have control over that query. Some defence against this is limiting number of returned / queried records on the service level. If user wants more records he must specify more detailed search criteria.
对于#2，每当引入抽象时，都会对性能进行权衡。它对您是否重要只能通过性能测试和针对您的情况进行分析来确定。阅读这篇文章，了解为什么要使用自定义 ORM，Dapper 是必需的，这样才能给你一个想法。 Dapper 还有一个性能测试套件您可以使用它来确定 EF 对典型查询的影响有多大。
还有一个#3。 EF 仍然不支持 SQL 的某些功能，这可能会限制您的设计。例如 唯一密钥尚不支持约束。
EF 仍在不断发展，请关注 ADO.Net 团队博客。
For #2 whenever an abstraction is introduced ther will be a trade-off with performance. Whetther it is significant for you or not can only be determined by performance testing and profiling in your situation. Read this post on why a custom ORM, Dapper was required for SO to give you an idea. Dapper also has a performance test suite you can use to ascertain how much of an impact EF will have on your typical queries.
There is also a #3. Some features of SQL are still not supported by EF and this could limt your design. e.g. Unique Key constraints are not supported yet.
EF is still evolving and keep an eye on the ADO.Net team blog.