Question

在将所有这些文章放在一起时，我对如何处理EF开发感到有些困惑，因为我找不到在一个地方解决所有这些实践的示例：

以下文章建议我在存储库中创建reusable caching layer for Azure（但它不实现IDisposable）
This article recommends that the context shouldn't be reused for more than one HTTP query
This article recommends I initialize the context / repository in the constructor，它通过覆盖控制器的dispose（）来处理上下文（存储库）。没有使用声明。
这篇文章说Using阻止has issues in WCF (link1) (link2) (link3)
这篇文章演示了将IDisposable与使用块一起使用的选项
这篇文章展示了MVC应用程序override Dispose() to get rid of the context

问题

我应该拨打Dispose吗？我应该在哪里调用它以确保上下文的适当生命周期？ ...在MVC应用程序中，这似乎是通过覆盖控制器的配置方法来完成的。
我应该如何处理上面链接的Azure缓存？ ......也许ObjectCache是我应该关注的唯一对象。
我应该使用使用，还是使用不值得信任的？
Microsoft是否应该提供解决所有这些问题的示例？该样本会是什么样的？（如果它不是this one）我在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对象无法处理 - 它们已经自行处理。这就是发生另一个错误的原因。这并不意味着使用不会调用dispose。鉴于这个事实是错误的，我甚至不会对你的结论发表评论 - 因为显然你的事实是错误的。

Answer 3

基本思路很简单。如果您使用的是IDisposable个实例，则需要调用Dispose方法。问题是这些实例的范围以及何时处理它们。一旦你完成它们就更好地处理它们。

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

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

我从来没有说[你] 应该超越方法

这些实体框架建议中的任何一个建议是否相互冲突？

3 个答案: