虽然SharePoint Server 2007使用了ASP.NET 2.0的基础页面模型，SharePoint页面基本上也是基于标准的ASPx技术来构建，但SharePoint Server 2007的页面模型仍然要比普通的ASP.NET应用复杂很多。对于一个SharePoint开发人员（和设计人员），了解SharePoint的页面模型是非常非常重要的。
在SharePoint 2007中，将页面分为两种：Application Page和Site Page。Application Page是指SharePoint应用程序中用到的页面。比如，当我们进入到一个SharePoint站点的站点设置中后，几乎所有的站点设置页面都是Application Page。如果我们看到地址栏中的页面路径都是类似“http://SharePointsite/_layouts/xxx.ASPx”这样的格式，也就是说，页面位于“_layouts”虚拟目录中，那么这个页面就是Applicatoin Page。Application Page在物理上被存放在SharePoint Web前端服务器的“Program FilesCommon FilesMicrosoft SharedWeb Server ExtensionsTEMPLATELayouts”目录中，不能被用户进行定制。而Site Page是指位于一个SharePoint站点中的普通页面。比如，站点的首页：“http://SharePointsite/default.ASPx”，或者位于一个文档库中的页面：“http://SharePointsite/pages/xxx.ASPx”，都是Site Page。
Application Page实际上和一个普通的ASP.NET 页面没有任何区别。开发人员如果有需要，可以自己添加新的Application Page，你既可以在“Program FilesCommon FilesMicrosoft SharedWeb Server ExtensionsTEMPLATELayouts”目录中添加新的页面，也可以在这个目录下创建新的子目录（或虚拟目录），来放置你的 Application Page。在Application Page中，开发人员可以根据自己的需求，直接添加In-line code，这些code都会直接被执行，就像一个普通的ASP.NET应用程序一样（当然，对于Code-behind的模式，Application Page也是支持的）。比如：
对于Application Page，SharePoint 2007总是认为它们是安全的，因为，站点的管理员（非服务器管理员）和用户都没有办法直接修改Application Page，所以，SharePoint 2007会直接“执行”它们。
如果你要创建自己的Application Page，尽量遵守这样的模式：
1、让你的Application Page从“Microsoft.SharePoint.WebControls.LayoutsPageBase”继承下来；
2、让你的Application Page使用位于Layouts目录中的“Application.master”这个Master Page；
3、在Layouts目录中创建一个新的子目录（或虚拟目录）来放你的Application Page，不要和SharePoint自带的Application Page混杂在一起。
Site Page比Application Page要更复杂一些。对于Site Page，我们通常根据它们是否已经被进行了定制（通过SharePoint Designer 2007），将Site Page分为Uncustomized Page和Customized Page。（在SPS2003中，使用的是Ghosted Page和Unghosted Page这两个术语。）
当我们新建一个站点的时候，所有的页面都是Uncustomized Page，这些页面都是直接使用了存放在SharePoint Web前端服务器磁盘上的页面模板（位于“Program FilesCommon FilesMicrosoft SharedWeb Server ExtensionsTEMPLATE”的各个子目录中），换言之，这个新站点的页面其实是“不存在的”，它们只是一个“标记”（这也就是在 SPS2003中，它们被称为Ghosted Page的原因），如果用户访问一个页面，SharePoint会自动从磁盘上找到那个真正的页面模板文件，然后将其载入到内存中，解析它，并将其编译成一个独立的dll文件（为了性能，这个dll会缓存在磁盘上以避免下次重复编译），然后载入这个dll，运行，输出。
但是，如果站点设计人员用SharePoint Designer 2007打开这个SharePoint站点，然后用SharePoint Designer打开某个Site Page文件，进行某些修改，保存，SharePoint会自动将修改后的文件内容保存到站点所用的内容数据库中，它就成了一个Customized Page。从此，这个Customized Page就和磁盘上的页面模板“脱离关系”了。当用户访问这个页面时，SharePoint会自动从内容数据库中读出这个文件的内容，然后对其进行解析，运行。注意！这次，SharePoint不会再将其编译成一个独立的dll文件了，实际上，SharePoint会在内存中载入这个页面的结构，运行，然后输出，然后将它从内存中卸载以节省内存。
从Uncustomized Page和Customized Page的运行模式上，我们就能看出它们的运行效率存在着不小的差别。首先，Uncustomized Page是位于磁盘上的，它的读入速度会比较快，其次，Uncustomized Page会在第一次被访问时就被编译成一个dll，避免了重复编译。比如，两个不同SharePoint站点的首页“default.ASPx”如果都是Uncustomized Page，而且使用的是同一个页面模板，它们只会被编译一次。而Customized Page位于内容数据库中，读入速度比不上磁盘文件，而且它不会被编译成dll，而是只会在内存中进行解析，运行。
但是，有意思的是，Customized Page的解析运行方式虽然在速度上可能要慢，但却要更节省内存一些。因为在内存中载入一个页面的结构，进行解析运行后，是可以再释放掉的，而一个dll 被载入后，是不能被释放掉的。这是因为.NET不支持载入程序集后再卸载程序集，呵呵。（但.NET支持创建AppDomain后再释放掉 AppDomain。）
除了存放位置和运行效率上的不同，在代码安全上，Uncustomized Page和Customized Page也存在很大的区别。
类似于Applicaton Page，Uncustomized Page也是被SharePoint信任的页面，位于Uncustomized Page里面的ASP.NET In-line code会被直接运行。而Customized Page由于可以被站点设计者（可能他并非是服务器管理员）通过SharePoint Designer向其中加任意的In-line code，所以，默认的安全规则根本不会允许Customized Page中的服务器端代码被运行。
类似的，如果Uncustomized Page上面被放置一个服务器端控件，是没有问题的，但是，如果要向Customized Page上放一个服务器端控件（包括Web Part），那么这个控件就必须在站点的web.config中被标识为“Safe Control”（也就是增加新的“<SafeControl>”节点来标识某个控件是安全的）。
虽然SharePoint对Customized Page有这些安全上的限制，但是，服务器管理员通过修改web.config文件中的安全设置，是可以更改这样的默认安全限制的。比如，如果你希望站点 的“MyPages”目录下的页面，即使它们是Customized Page，也允许被包含服务器端In-line code，可以在web.config中增加这样的内容：
“CompilationMode”节点的值可以是：Never、Always和Auto，将其设置为Always，就可以强制进行编译。 “AllowServerSideScript”是指定是否允许服务器端的代码，“AllowUnsafeControl”是指定是否允许非安全（也就是 没有在“SafeControls”区域指定为安全）的控件。
最后要提醒的是，虽然通过修改web.config中的设置可以让所有的Site Page都能包含服务器端代码，但如非必要，尽量不要这样做。因为这将会使有权限对站点进行设计的人，通过使用SharePoint Designer，就可以在任何页面中添加In-line code，来进行任何操作。