So, the thought behind this metaphor is that these two SharePoint object model classes are really two representations of one and the same internal piece of data (or being). Basically this means that when you make one of the objects you involuntarily get the other one, when you delete one of them, the other one also gets deleted and when you exchange the properties of one of them you see visual or other changes in the other. So, list views in SharePoint always come with a pair of representing objects – a ListViewWebPart and SPView – and since behind them is a single being you can’t have one of the objects in the pair replaced with another SPView or LVWP. In SharePoint 2010 with the introduction of the LVWP inheritor – the XSLT list view web part (XLV) you have the same pairing but with the XLV instead of the LVWP on the web part side.

So, to clarify the above mentioned let me present several examples from the SPView and LVWP perspectives –first, what do we have from the SPView class perspective:

• When you make a new SPView (from code or the UI alike) you get a web part page (in the list root folder or in the Forms subfolder of the list) containing a LVWP on it that displays the target list’s data. The deleting of the SPView deletes the web part list view page together with the LVWP on it. So far, it sounds rather mundane, doesn’t it?
• But the more fascinating part is when you have the list view web part page and delete the LVWP part on it by the SharePoint UI (you may do that with code too) – the result is that the SPView object that has made the containing web part view page is also deleted – that’s probably something you haven’t probable to happen (be precise to not delete the defaulting view this way). This way you will end up with an empty view (really ex-view) web part page and no SPView – you can inspect the Views collection property of the containing SPList to make sure that the corresponding SPView is really gone.

And what do we have from the LVWP perspective:

• When you add a LVWP to a publishing or simple web part page with the UI or code you will get a new SPView in the parent list’s Views collection. The new SPView will have its Hidden property set to right and its DisplayName will be empty. The Guid ID property of the SPView will be the same as the ViewGuid property of the LVWP but also as the ID property itself of the LVWP (save that the ID of the LVWP has the “g_” prefix).
• When you exchange the Query property or the ViewFields of this hidden SPView you will see that the changes will become immediately visible in the LVWP. Note that if you have the LVWP on a publishing page that requires check-out you will need to have the page check out first otherwise you will receive an error when you call the SPView.Update method (I will show a code snippet not more than how this can be achieved).
• When you delete the LVWP its hidden SPView also gets deleted. It’s the same the other way around – if you delete the hidden SPView, the LVWP will get deleted (you don’t need to have the page check out in this case – remember that pretty much the same happens if you delete the SPList itself – then all LVWP based on it get deleted)
• Another note here – the standard UI for editing the properties of the LVWP is a small bit misleading – you see a drop-down from which you can select one of the existing visible SPViews for the LVWP – you may reflect that this way you associate the SPView with the LVWP but this is not the case – what happens really is that the machinate of the visible SPView gets hackneyed to the LVWP’s own hidden SPView. You can see that this is the case reasonably easily – if you modify the visible view that you have “associated” with the LVWP you’ll see that the changes won’t be applied to the LVWP.
• It’s pretty much the same when you add a LVWP to a page with code: in this case you need to make a new instance of the ListViewWebPart class and set its ListName property and any the ViewGuid or ListViewXml properties. When you set the former, you need to provide the guid ID of an existing SPView – you will notice but that after the LVWP is already added to the page the ViewGuid property now has the ID of its internal SPView not the original one. If you use the ListViewXml you should provide the view machinate yourself (to cut a long tale small you can use for example the SchemaXml property of the SPView returned by SPList.GetUncustomizedViewByBaseViewId) – then you will have full control over the various parts of the view machinate – query, view fields, etc.

So let me now show you several examples of how you can update the LVWP’s hidden SPView with the SharePoint UI and with code and to briefly outline the cases when you may need to do that (just to quickly announce here that there is some excellent news for SharePoint 2010 about that).

Starting with SharePoint 2007 – from a user interface perspective you can modify the LVWP’s SPView’s machinate by getting the web part in edit mode and clicking the “Edit the current view” link in the part’s properties pane – this will open the standard “modify view” attention page. Another option here is to select another existing view from the “Selected View” drop-down.

A case in which you don’t have control over certain aspects of the part’s hidden SPView’s machinate is when you provision LVWPs with Module features. Basically all you can specify in this case is a “BaseViewID” (which will define the presentation part) but nothing for the view’s query, view fields, etc. So this issue can be resolved only with code – there’re two options here – to any add the LVWPs to the pages with code (manipulating the ListViewXml property) or have the part’s hidden SPView modified after the web parts is already made (with the UI or provisioned with a Module feature). The latter is a small bit tough, here is a code snippet that can achieve that:

Notice that the page containing the LVWP may need to be check out before the SPView instance can get updated. Also note that the SPView object should be retrieved only after the page is check out.

The SharePoint 2010 tale

Several pieces of excellent news here starting with the new XLV web part which comes with numerous improvements over the SharePoint 2007’s LVWP (there is an on-going series on that on the MS SharePoint team blog). One of the main improvements here relevant to this posting is that the presentation settings were went from the SPView class to the web part itself – the Xsl and XslLink properties of the XLV instead of the cumbersome CAML holding presentation properties in SPView. This means that you can get the query machinate hackneyed from existing views with the UI but can provide your custom rendering in the web part itself (remember the problem with free form views in the announcement list in SharePoint 2007).

Another “goodie” in SharePoint 2010 is that you can directly use the standard view editing page (_layouts/ViewEdit.aspx) to modify the XLV’s hidden SPView – you have the button in the ribbon (I like the ribbon already). So you don’t need to do the cumbersome stuff as in SharePoint 2007 – getting the properties pane of the web part opened, etc., but you can just select the XLV (the blue border around the part should appear) so that the “ListTools” tab appears in the ribbon, and then from the “List” sub-tab select “Modify View” – see the image (on a publishing page you will need to have the page check out otherwise you’ll receive an error when you try to update the view in the view editing page):

Notice that the the standard view editing page opens but with the text field for the show name and the check-box for defaulting view hidden (this is a hidden SPView after all), also the delete button is missing, but if you are persistent you can delete the SPView with code (which will of course delete the XLV too):

Check it out:Stefan Stanev’s SharePoint blog