C# 何时不使用实体框架

When NOT to use the Entity Framework

提问by driAn

I have been playing around with the EF to see what it can handle. Also many articles and posts explain the various scenarios in which the EF can be used, however if miss the "con" side somehow. Now my question is, in what kind of scenarios should I stay away from the Entity Framework?

我一直在玩 EF，看看它可以处理什么。还有许多文章和帖子解释了可以使用 EF 的各种场景，但是如果以某种方式错过了“骗局”方面。现在我的问题是，在什么样的场景中我应该远离实体框架？

If you have some experience in this field, tell me what scenarios don't play well with the EF. Tell me about some downsides you experienced where you whished you would have chosen a different technology.

如果您在该领域有一些经验，请告诉我哪些场景不适用于 EF。告诉我您在希望选择不同技术时遇到的一些缺点。

采纳答案by Duncan

I'm also just at the 'playing around' stage, and although I was worried about the lack of built-in persistence agnosticism, I was sure there would be a "work-around".

我也只是在“玩弄”阶段，虽然我担心缺乏内置的持久性不可知论，但我确信会有一个“解决方法”。

In fact, not even a work-around in an n-tier architecture.

事实上，在 n 层架构中甚至都不是解决方法。

WCF + EF

WCF + EF

If I've read the articlecorrectly, then I don't see any problem serializing entities across the wire (using WCF) and also the persistence ignorance isn't a problem.

如果我正确阅读了这篇文章，那么我在网络上（使用 WCF）序列化实体时看不到任何问题，而且对持久性的无知也不是问题。

This is because I'd use PI mainly for unit-testing.

这是因为我主要将 PI 用于单元测试。

Unit Testing ispossible! (i think)

单元测试是可能的！（我认为）

In this system, we could simply use a mock service (by wrapping up the call to the service in ANOTHER interface based class which could be produced from a factory, for example). This would test OUR presenter code (there's no need to unit-test the EF/DAL - that's Microsoft's job!) Of course, integration tests would still be required to achieve full confidence.

在这个系统中，我们可以简单地使用模拟服务（例如，通过在另一个基于接口的类中包装对服务的调用，该类可以从工厂生产）。这将测试我们的演示者代码（不需要对 EF/DAL 进行单元测试——这是微软的工作！）当然，仍然需要集成测试才能获得充分的信心。

If you wanted to write to a separate database, this would be done in the DAL layer, easily achieved via the config file.

如果你想写入一个单独的数据库，这将在 DAL 层完成，通过配置文件很容易实现。

My Tuppence Worth

我的塔彭斯值得

My opinion - make up your own mind about the EF and don't be put off by all the doom and gloom regarding it that's doing the rounds. I'd guess that it's going to be around for a while and MS will iron out the faults in the next year or so. PI is definitely coming in according to Dan Simmons.

我的意见 - 对 EF 做出自己的决定，不要被所有关于它的厄运和悲观所拖延。我猜它会持续一段时间，MS 会在明年左右解决这些问题。根据丹·西蒙斯（Dan Simmons）的说法，PI 肯定会进来。

EDIT: I've just realised I jumped the gun and like a good politician didn't actually answer the question that was asked. Oops. But I'll leave this in in case anyone else finds it useful.

编辑：我刚刚意识到我跳了起来，就像一个优秀的政治家一样，实际上并没有回答被问到的问题。哎呀。但我会留下这个以防其他人觉得它有用。

回答by Ryan Michela

One potentially big issue: Entity Framework 1.0 does not support persistence ignorance. This means that your business layer has a dependency on your data access layer.

一个潜在的大问题：Entity Framework 1.0 不支持持久性无知。这意味着您的业务层依赖于您的数据访问层。

If your entire application will be hosted in the same process (like a website on IIS) then this is no problem.

如果您的整个应用程序将托管在同一进程中（如 IIS 上的网站），那么这没问题。

If, however, you have a need to remote your entities (to a Silverlight or Windows Mobile client for example), then your entities will not easily serialize across the wire. You will have to create separate data transfer classes to send your entities across the wire, and additional logic to marshal data between your entity classes and the DTOs.

但是，如果您需要远程连接实体（例如，连接到 Silverlight 或 Windows Mobile 客户端），那么您的实体将无法轻松地通过网络进行序列化。您必须创建单独的数据传输类以通过线路发送您的实体，以及在您的实体类和 DTO 之间编组数据的附加逻辑。

Edit:spelling.

编辑：拼写。

回答by Bramha Ghosh

Since EF does not support POCO, it can be difficult to write good unit tests against. That was one of the knocks against it in the Vote Of No Confidence.

由于 EF 不支持 POCO，因此很难针对其编写好的单元测试。这是不信任投票中对它的打击之一。

If you're wanting to write good tests, EF will raise obstacles. You can work around them, but it is non-trivial.

如果您想编写好的测试，EF 会设置障碍。您可以解决它们，但这很重要。

回答by Corbin March

Not all data models map nicely to application Entities. If the mapping isn't relatively straightforward, I'd skip the Entity Framework. You'll find yourself doing handstands to make it work without any clear benefit.

并非所有数据模型都能很好地映射到应用程序实体。如果映射不是相对简单，我会跳过实体框架。你会发现自己倒立是为了让它工作而没有任何明显的好处。

Anders Hejlsberg had some interesting comments about object/relational mapping here.

Anders Hejlsberg 在这里有一些关于对象/关系映射的有趣评论。

回答by Daniel Auger

The Vote of No Confidencelists several missteps and/or missing bits of functionality in the eyes of those who believe they know what features, and their implementations, are proper for ORM/Datamapper frameworks.

该投票不信任列出了几种失误和/或在那些谁相信他们的眼睛的功能失位知道有什么特点，以及它们的实现，是正确的ORM / DataMapper的框架。

If none of those issues are a big deal to you, then I don't see why you shouldn't use it. I have yet to hear that it is a buggy mess that blows up left and right. All cautions against it are philosophical. I happen to agree with the vote of no confidence, but that doesn't mean you should. If you happen to like the way EF works, then go for it. At the same time I'd advise you to at least read the vote of no confidence and try to get a rudimentary understanding of each of the issues in order to make an informed decision.

如果这些问题对你来说都不是什么大问题，那么我不明白你为什么不应该使用它。我还没有听说这是一个左右爆炸的马车混乱。所有反对它的警告都是哲学的。我碰巧同意不信任投票，但这并不意味着你应该。如果您碰巧喜欢 EF 的工作方式，那就去做吧。同时，我建议您至少阅读不信任投票，并尝试对每个问题有一个基本的了解，以便做出明智的决定。

Outside of that issue and to the heart of your question - You need to keep an eye on the Sql that is being generated so you can make tweaks before a performance problem gets into production. Even if you are using procs on the backend, I'd still look for scenarios where you may be hitting the database too many times and then rework your mappings or fetching scenarios accordingly.

在该问题之外以及问题的核心 - 您需要密切关注正在生成的 Sql，以便您可以在性能问题进入生产之前进行调整。即使您在后端使用 procs，我仍然会寻找您可能多次访问数据库的场景，然后相应地重新设计映射或获取场景。

回答by Scott

Though both SQL CE 3.5 SP1 and Entity Framework 4.0 Beta 1 both support Identity Columns, using these two products together (at least up to the versions listed), Identity Columns are not supported. You will be required to set primary keys on your own.

尽管 SQL CE 3.5 SP1 和 Entity Framework 4.0 Beta 1 都支持标识列，但将这两种产品一起使用（至少到列出的版本），不支持标识列。您将需要自己设置主键。

Other than that, I've been enjoying EF with SQL CE.

除此之外，我一直在享受带有 SQL CE 的 EF。