Proper use of SPWeb from SPContext for pulling lists

Question

So, after about two hours on the subject I am thoroughly confused. There are viewpoints all over the place on how, when, and why to use Dispose() on SPWeb objects as they relate to SPContext.

Can someone clear this up for me in a specific context? I am creating a Site Definition that instantiates lists, so assume that I can ALWAYS pull the lists from SPContext. There is never a danger of a console or powershell execution.

The rule seems to be, never, ever, ever dispose of the SPContext.Current.Web object. Does that rule also apply to mirror instances? Meaning:

using (SPWeb web = SPContext.Current.Web)
{
    SPList TargetList = web.GetList(web.ServerRelativeUrl + "/lists/Post");
    SPListItemCollection items = TargetList.GetItems(query);
}

vs

SPList TargetList = SPContext.Current.Web.GetList(SPContext.Current.Web.ServerRelativeUrl + "/lists/Post");
SPListItemCollection items = TargetList.GetItems(query);

Is there a real, qualitative difference here? Do I not save a process cycle by NOT instantiating a new object, which really just serves as a placeholder?

Would there be danger in writing a data access object like this?

public static SPList PostList()
{
  return SPContext.Current.Web.GetList(SPContext.Current.Web.ServerRelativeUrl + "/lists/Post");
}
static public List<Post> GetPostsByCommunity(string CommunityName) 
{
    SPList TargetList = PostList();
    SPListItemCollection items = TargetList.GetItems(query);
}

Since the lists I am working with are a small collection of 4, I could have static objects for each, and then have very tight and simple Data Access methods which return Objects populated by the returned information.

(Ignoring the lack of query and looping. I want to focus purely on the data access)

Tell me why this is a bad idea and what is the right way to do this.

Answer 1

You are correct, never dispose an object retrieved from a Property from SPContext.

The simple reason being, you can never be sure that there is another thread, control or other piece of code that executes after your code does and is expecting that properly to exist.

Your first two examples (where you put one versus the other) are functionally identical, except you dispose of the Web property of SPContext.Current in the second, which is ill-advised.