Do any of these Entity Framework recommendations conflict with each other?

Question

I'm a little confused on how to approach EF development when looking at all these articles together, since I can't find a sample that addresses all of these practices in one place:

• The following article recommends that I create a reusable caching layer for Azure in a repository (but it doesn't implement 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, it disposes of the context (repository) by overriding the controller's dispose(). There is no using statement.

• This post says that the Using block has issues in WCF (link1) (link2) (link3)

• This post demonstrates an option to use IDisposable with the using block

• This post shows an option where MVC applications override Dispose() to get rid of the context

Question

1. Should I call Dispose? Where should I call it to ensure proper lifetime of the context? ... In an MVC app this seems to be done by overriding the controller's dispose method.

2. How should I dispose of the Azure cache linked above? ... Perhaps ObjectCache is the only object I should be concerned about.

3. Should I use Using, or is using untrustworthy?

4. Should Microsoft produce a sample that addresses all these issues? What would that sample look like? (if it's not this one) Most samples I see with EF + MVC have a varying and inconsistent implementation. I'm not sure who to imitate in my project.

Answer 1

You have drawn conclusions unnecessarily.

The WCF issue is a desgn flaw. Microsoft screwed up. It happens sometimes.

I no longer have the reference, but I found it by searching, and you can too. There was a point during the design of WCF where the question came up, "should Dispose() just always call Close()". When the question came to Don Box (the Chief Architect of WCF or some such title), he "couldn't think of any reason why not". He missed a reason why not.

Dispose() must not throw exceptions. This is because of the following:

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?
}

If Dispose() throws Exception2, then I will lose Exception1 along with the stack trace showing me what happened. The problem is that Mr. Box found no reason why Dispose() shouldn't just call Close() to do the job. The problem is that, with some bindings, Close() actually has to do some work. This is the case with wsHttpBinding, where there is a message exchange upon Close(). This means ther's a real chance of Close() throwing an exception, trashing my call stack.

Answer 2

Start checking your facts - they are wrong. The article about using being unreliable does not say it is unreliable. WCF objects that are in a faulted state can not be disposed - they are already self-disposed. This is why another error occurs. It does not mean using does not call dispose. Given that this fact is wrong, I would not even tart commenting on your conclusions - because obviously your facts are wrong.

Answer 3

The basic idea is very simple. If you are using IDisposable instances you need to call the Dispose method. The problem is the scope of those instances and when you are going to dispose them. Better to dispose them as soon as you are done with them.

People implement the repository pattern in various ways depending on their requirements. So those implementations may not work for you. Work out whats best for you.

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

I never said [you] should over ride the method