这些实体框架建议是否相互冲突？

Question

当我一起查看所有这些文章时，我对如何进行 EF 开发有点困惑，因为我找不到在一个地方解决所有这些实践的示例：

• 下面的文章建议我创建一个 < a href="http://msdn.microsoft.com/en-us/gg457899" rel="nofollow noreferrer">存储库中的 Azure 可重用缓存层（但它没有实现IDisposable)

• 本文建议不要将上下文重复用于多个 HTTP 查询

• 本文建议我在构造函数中初始化上下文/存储库，它通过重写控制器的 dispose() 来处置上下文（存储库）。没有 using 语句。

• 这篇文章说 Using 块WCF 中存在问题 (link1) (link2) <一href="http://social.msdn.microsoft.com/forums/en-US/wcf/thread/b95b91c7-d498-446c-b38f-ef132989c154/" rel="nofollow noreferrer">(link3)

• 这篇文章演示了使用IDisposable 与 using 块

• 这篇文章展示了 MVC 应用程序 覆盖 Dispose() 以摆脱上下文

问题

1. 我应该调用 Dispose 吗？我应该在哪里调用它以确保上下文的正确生命周期？ ...在 MVC 应用程序中，这似乎是通过重写控制器的 dispose 方法来完成的。

2. 我应该如何处置上面链接的 Azure 缓存？ ...也许 ObjectCache 是我应该关心的唯一对象。

3. 我应该使用Using，还是使用不可信？

4. Microsoft 是否应该制作一个解决所有这些问题的示例？该样本会是什么样子？ （如果不是 这个）我看到的大多数使用 EF + MVC 的示例都有不同且不一致的实现。我不确定在我的项目中要模仿谁。

Answer 1

你得出了不必要的结论。

WCF 问题是一个设计缺陷。微软搞砸了。有时会发生这种情况。

我已经没有参考文献了，但是我通过搜索找到了它，你也可以。在 WCF 的设计过程中，有一个问题出现了：“Dispose() 应该始终调用 Close()”。当这个问题问到 Don Box（WCF 的首席架构师或类似头衔）时，他“想不出任何不这样做的理由”。他错过了一个不这样做的理由。

Dispose() 不得抛出异常。这是因为：

try
{
    var proxy = null;
    try
    {
        proxy = new ProxyClass();
        throw new Exception1();
    }
    finally
    {
        if (proxy != null) proxy.Dispose(); // What happens if this throws Exception2?
    }
}
catch (Exception ex)
{
    // Which exception do I see in here?
}

如果 Dispose() 抛出 Exception2，那么我将丢失 Exception1 以及显示发生情况的堆栈跟踪。问题是 Box 先生没有发现为什么 Dispose() 不应该只调用 Close() 来完成这项工作。问题是，对于某些绑定，Close() 实际上必须做一些工作。 wsHttpBinding 就是这种情况，其中在 Close() 上进行消息交换。这意味着 Close() 很有可能抛出异常，从而破坏我的调用堆栈。

Answer 2

开始检查你的事实——它们是错误的。关于使用不可靠的文章并没有说它不可靠。处于错误状态的 WCF 对象无法被处置 - 它们已经被自行处置。这就是另一个错误发生的原因。这并不意味着使用不调用处置。鉴于这个事实是错误的，我什至不会对你的结论发表评论——因为显然你的事实是错误的。

Answer 3

基本思想非常简单。如果您使用 IDisposable 实例，则需要调用 Dispose 方法。问题在于这些实例的范围以及何时处置它们。最好在用完后立即处理掉它们。

人们根据他们的需求以各种方式实现存储库模式。所以这些实现可能不适合你。找出最适合你的。

This post says my MVC applications should override Dispose() to get rid of the context

我从未说过[你]应该重写该方法