我们都知道，在SharePoint中，Content page继承自Page layout，而Page layout又继承自Master page。Master page的作用大家都知道，它定义了站点的的整体外观和公共元素，因此有了很强的页面重用性和很好的页面编辑体验，Page layout通过ContentPlaceHolder为一些内容相似性很强的页面进行了布局，所以到了Content page那里，我们所做的只是放我们每个页面想要显示的内容即可，剩下的布局和样式都可以不用操心了。
好了，前面算是开场白吧！现在我们正式说重点，先从需求说起，客户要求整个站点的Footer部分要求从站点的List里面动态读取数据来生成它，而不是写死在master page里面，例如下面的图示，也就是说客户希望将来他们可以通过维护一个List数据来动态更新站点的Footer部分，附加排序，是否显示等功能，都有List里面的某个字段来控制，而不再需要有IT人员去更新了。
对于这个需求，我们可以有如下几种实现方式：
（一） 首先想到的是写一个Customized User Control，通过调用Object Model来呈现数据。部署完了dll以后，需要在Master Page里注册引用，然后才能去使用它，这里不再多说具体过程。这种方法好是好，但是不易维护，如果有任何逻辑改动，还需要重新部署dll到服务器端，很多时候不是很方便。
（二） 第二种方式是借助于Content Query Web Part，有人会说Master Page里面可以放Web part吗？动态的web part是不能加到Master page里的，因为Master page的内容是不允许从页面上修改的，但是我们可以放静态的web part，所谓静态的就是说web part不在web part zone里面。具体步骤如下：
1． 先建一个临时的测试页面，添加一个Content Query Web Part, 然后配置web part，如数据源，过滤条件及排序等属性。
2． 用SPD将次页面跟layout分离，然后打开它，找到相应的web part zone，我们发现zone里面是一个<PublishingWebControls:ContentByQueryWebPart>，其实它就是一个控件，将此控件拷贝出来放到Master page相应的html元素中即可，注意不要web part zone。
3． 更新List数据并刷新页面可以看到Footer是动态变化的了。注意：有时候换了环境可能会出现这个错误：There is a problem with the query that this Web Part is issuing. Check the configuration of this Web Part and try again. 这是因为ListGUID变了，所以必要的时候我们可以通过ListUrl和ListName属性来控制，而不再使用ListGUID。
（三） 第三种方式也是借助web part，只不过换成是Data View Web Part，所以跟第二种方式大体上应该差不多，就不再细说了。
以上几种方式，各有优缺点，相对来讲，第二种或第三种更容易维护，因为他们是OOB的，不涉及到服务器端代码，如果客户不让写服务器端代码，那么此时选择后者再合适不过了。也许还有其他更好的方式，有待探究。
转自：http://blog.csdn.net/crazysharepoint/article/details/6046903