何时不使用实体框架

.net architecture c# entity-framework

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

如果你在这个领域有一些经验,请告诉我哪些场景不适合EF。告诉我你经历过的一些缺点,你会选择不同的技术。

一般承认的答案

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

事实上,甚至在n层架构中都没有解决方案。

WCF + EF

如果我正确地阅读了这篇文章 ,那么我没有看到任何问题通过网络序列化实体(使用WCF),并且持久性无知也不是问题。

这是因为我主要使用PI进行单元测试。

单元测试可能的! (我认为)

在这个系统中,我们可以简单地使用模拟服务(通过在基于另一个接口的类中包含对服务的调用,例如可以从工厂生成)。这将测试我们的演示者代码(不需要对EF / DAL进行单元测试 - 这是微软的工作!)当然,仍然需要进行集成测试才能充分发挥自信。

如果你想写一个单独的数据库,这将在DAL层完成,可以通过配置文件轻松实现。

我的Tuppence值得

我的观点 - 对EF进行自己的思考,并且不要因为那些正在进行巡回赛的所有厄运和沮丧而被推迟。我猜它会在一段时间内出现,MS会在明年左右解决这些问题。根据Dan Simmons的说法,PI肯定会出现。

编辑 :我刚刚意识到我跳了枪,就像一位优秀的政治家实际上没有回答被问到的问题。哎呀。但我会留下这个以防万一其他人发现它有用。


热门答案

无信任投票列出了那些认为他们知道什么功能及其实现适合ORM / Datamapper框架的人眼中的几个失误和/或缺失的功能。

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

除了这个问题和问题的核心 - 您需要密切关注正在生成的Sql,以便在性能问题投入生产之前进行调整。即使你在后端使用过程,我仍然会寻找你可能会多次访问数据库的情况,然后重新编写映射或相应地获取方案。




许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow
这个KB合法吗? 是的,了解原因
许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow
这个KB合法吗? 是的,了解原因