1

I am writing a MVC3 application, using NInject DI and repository pattern. Ninject is set up so that the repositories have a per-request lifetime.

I am putting the context object into the Http Request object, using the following code:

    public static MessengerEntities GetContext()
    {
        if (!HttpContext.Current.Items.Contains("_db_context"))
        {
            HttpContext.Current.Items.Add("_db_context", new MessengerEntities());
        }
        return (MessengerEntities)HttpContext.Current.Items["_db_context"];
    }

Then each repository calls this procedure to get either an existing or a new context object, e.g.:

public class TestRepository : ITestRepository
{
    private MessengerEntities context = ContextHelper.GetContext();

    #region ITestRepository Members
    private string _testProperty = "blah";
    public string testProperty
    {
        get
        {
            _testProperty = context.UserLogins.Where(n => n.inactive == null || !n.inactive.Value).ToList().Count.ToString();
            return _testProperty;
        }
        set
        {
            _testProperty = value;
        }
    }

    #endregion
}

(Later on, I plan to use a generic IRepository pattern, but for now I am just using this test repository.)

My question is: when the Request object is disposed of, will it also dispose of the context object in the Items collection? In other words, will it call Dispose on each object that may be stored in that collection?

I know there are a lot of discussions about this issue here, but they all seem to involve scenarios that are not quite the same as mine, so it's kind of hard to divine the answer.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Cynthia
  • 2,100
  • 5
  • 34
  • 48
  • Wow, what happened to the answer that Darrin (I think that was his name) gave, and the several comments, and ... ?? I came here to mark his answer as the correct one, and now it's not here! – Cynthia Feb 24 '11 at 20:08
  • Anyway, Darrin said that this scenerio would work because all the objects would be marked for deletion by the garbage collector, though when the garbage collection actually took place was not certain. But that's OK with me, as the repositories would hold the only pointers to the context, and they would be disposed of after each request. – Cynthia Feb 24 '11 at 21:32
  • @Cynthia, Darin deleted his answer, but didn't say why. Here's a comment I wrote on that answer before he deleted it: Don't do this! An object which supports IDisposable should be disposed. Yes, the finalizer (not destructor!) will eventually run, but you've likely pushed your allocations back a generation in the GC, resulting in memory bloat and application freezes. However, the "better way" in the blog post doesn't have these problems and is fine. – Craig Stuntz Feb 24 '11 at 21:34
  • @Craig: OK, maybe your comment caused him to delete his answer. However, unfortunately I have lost the link to his "better way". As I recall, it used Ninject to create the context object with each request and dispose of it at the end. But he also had stuff in there using MVC service locator, which I don't understand entirely and didn't think I had time to research, so I sort of rejected his better way. However, if you have a link to that, I can revisit it. – Cynthia Feb 24 '11 at 21:49
  • @Cynthia, link is here: http://buildstarted.com/2010/08/24/dependency-injection-with-ninject-moq-and-unit-testing/ – Craig Stuntz Feb 24 '11 at 22:13
  • @Craig -- I started a new thread here http://stackoverflow.com/questions/5145775/ninject-doesnt-call-dispose-on-objects-when-out-of-scope (because I am not finding that Ninject disposes of objects) – Cynthia Feb 28 '11 at 18:10

0 Answers0