2011年1月8日
#
WSS 超越 ASP.NET 的一个强项是可以在不改变前台 Web 文件系统的情况下，能够提供并且定制页面。通过 WSS 的这个能力，可以将 .aspx 和 .master 页面保存在内容数据库中，在处理请求的时候，可以从内容数据库中获取定制版本的 aspx 页面和 master 页面。
考虑一下页面定制工作在 WSS 中的工作。想象你想为某个特定的站点修改主页 default.aspx 的页面布局 ,当你修改完成并且保存页面的时候，WSS 将修改后的内容保存到内容数据库，然后，当这个页面被请求的时候，WSS 必须从内容数据库中获取这个定制页面，下面我们讨论实现的架构。
ASP.NET 2.0 引入了一个新的可插拔的组件称为：Virtual Path Provider，它抽象了 ASP.NET 获取页面的来源，默认情况下，ASP.NET 提供了一个基于文件系统的 Virtual Path Provider。通过创建一个自定义的 Virtual Path Provider，开发人员可以通过自定义的组件来从希望的位置获取页面，例如 SQL Server。
在 WSS 中，SPVirtualPathProvider 就是这样一个组件，这个组件通过 SPRequestModule 组件结合进处理过程，在 SPRequestModule 中包含注册 SPVirtualPathProvider 的代码
SPVirtualPathProvider 在 WSS 中扮演了一个关键角色，提供了页面的定制化，同时它还支持另外一个重要的称为 page ghosting 的优化。这是 WSS 跨越在 farm 中的所有站点，提供成千上万个页面的关键因素。
想象一下你刚刚通过空的站点模板创建了一个包含 100 个站点的 WSS。如果没有站点需要定制化的主页，还需要复制 100 个主页到内容数据库吗？当然不，在 WSS 站点中的页面，像 default.aspx 将会基于页面模板，保存在 Web 服务器的文件系统中。页面模板用来提供页面对象的实例，访问的地址类似：http://sample.com/default.aspx。
当通过页面模板提供页面实例的时候，对于没有定制化的页面，WSS 不需要访问内容数据库，而是通过文件系统来获取。这被称为 ghosting 的页面。
页面的 ghosting 消除了对于内容数据库的访问，也使得众多不同的站点使用同样的页面模板成为可能。对于每一个 Web 应用程序，页面模板将会被编译为 DLL ，加载到内容中，这些优化成为 WSS 在高访问量的环境下提高性能的关键因素。
当你修改一个页面，并保存定制化版本的时候，将会被保存到内容数据库中。就不能使用 ghosting page 了，必须从内容数据库获取定制化的版本，由于这个原因，定制化的页面有时被称为 unghosted page。
原文地址：VS 2010 SP1 (Beta) and IIS Express
IIS Express 是一个 IIS7.5 对于开发者进行优化的免费版本，它既容易使用，又像 IIS 一样强大。
- 少于 5 M 的安装文件，轻量级又容易安装。
- 在 Visual Studio 中进行调试或者运行的时候不需要管理员账号
- 支持完全的 Web Server 特征，包括 SSL, URL 重写，和其他的 IIS7 模块
- 支持和允许扩展模块和 IIS7.x 中 web.config 支持的设置。
- 可以与 ASP.NET Development Server 同时安装和使用，而互不影响。
- 支持 Windows XP 或者更高的版本，提供全功能的 IIS 7.x 的特征。
IIS Express 可以从磁盘上直接启动，不需要注册表或者配置步骤，所以非常方便使用。
在 Visual Studio 2010 SP1 中增加了 IIS Express 的支持。
下载和安装 IIS Express
IIS Express 并不包含在 VS2010 SP1 中，它需要单独下载和安装，大约 4 M 的文件。使用这个链接下载，它使用 WebPI 来安装。
一旦 IIS Express 被安装，VS2010 SP1 将会启用一些额外的 IIS Express 命令和对话框来方便你使用它。
对于存在的项目启用 IIS Express
Visual Studio 现在的 Web 项目默认使用内建的 ASP.NET Development Server ，也称为 Cassini 。
将现有的项目转换为使用 IIS Express 非常简单，打开项目的属性对话框，点击 Web 窗格，在窗格中选中 "User IIS Express" 复选框。
更加简单的方法是，在项目上的右键菜单中选择 "Use IIS Express..." 菜单命令。
以后，当你运行或者调试项目的时候，将会看到 IIS Express 启动并且自动运行。
在 IIS Express 上的右键菜单中，可以浏览现在运行在 IIS Express 上的应用和网站。
注意如果你想回到 ASP.NET Development Server 上，你可以在项目上右键菜单中选择 "Use Visual Studio Development Server"，或者在项目的属性窗口中，将 Web 窗格中的 IIS Express 复选框取消。下次运行的时候，将会生效。
IIS Express 的属性
Visual Studio 2010 SP1 提供了一些新的 IIS Express 配置选项，在 ASP.NET Deveopment Server 中是没有的。一些通过项目的属性来提供。
例如，启用类似 SSL 支持，在 ASP.NET Development Server 中是没有的，可以通过简单改变 SSL Enabled 属性为 True 来完成。
一旦设置完成，对于这个项目 IIS Express 将会提供 HTTP 和 HTTPS 两个端点提供访问。
SSL 自签名证书
IIS Express 提供了一个自签名证书，在安装的时候被直接安装，这使得在开发过程中不再需要自己提供证书。一旦你改变了上面的下拉列表来启用 SSL，你就可以通过 https://url/ 来通过 SSL 连接了。
对于浏览器来说，例如 IE 将会提出一个警告，你的证书是不被信任的。
你可以标记这个证书作为信任的证书来忽视它，或者仅仅保持这个证书的非信任状态，点击 Continue 。
额外的 IIS 设置
IIS Express 使用它自己的每用户的 ApplicationHost.config 文件来配置默认的服务器行为。因为是针对每用户的，所以，可以被开发人员配置而不需要管理员身份，你可以定制所有的 IIS 特征和设置。
不过，我们强烈建议将所有的配置信息作为项目的一部分配置在 web.config 文件中，这样发布就会变得比较容易。
将 IIS Express 作为你的默认 Web 服务器
你可以配置 Visual Studio 将 IIS Express 作为默认的 Web 服务器，在 Tools -> Options 菜单中，打开 Projects and Solutions 节点，在 Web Projects 中 选中 'Use IIS Express for new file-based web site and projects'，将会使 Visual Studio 对新创建的网站和项目使用 IIS Express。
原文地址：VS 2010 SP1 (Beta) and IIS Express
原文地址：Must Everything Be Virtual With NHibernate?
老赵在博文中 我对NHibernate的感受（2）：何必到处都virtual 提到这篇文章，顺便翻译一下。
如果你使用过 NHibernate 2.0 或者以后的版本，毫无疑问你将会遇到过几次下面的异常：
NHibernate.InvalidProxyTypeException: The following types may not be used as proxies:
NHibernateExamples.Entities.OrderLine: method get_UnitPrice should be ‘public/protected virtual’ or ‘protected internal virtual’
NHibernateExamples.Entities.OrderLine: method set_UnitPrice should be ‘public/protected virtual’ or ‘protected internal virtual’
哎！我们忘了将 OrderList 实体的 UnitPrice 属性设置为 virtual 了。但是，为什么这里必须要设置为 virtual 呢？对于许多 NHibernate 的新手来说，这是一个问题。
对于这个问题的简单答案是：将成员设置为 virtual 是为了延迟加载。
更为详细的答案也更加有趣。 对于真正的 ORM 来说，必须具备的一个重要特征是透明的延迟加载。如果你通过 ORM 来获取一个对象，你不会希望它自动的将相关的整个对象图都拉过来（不包括默认情况），你也不会浪费你的代码来检查相关的对象是否已经加载了。应该在需要的时候加载它们，这是 ORM 的责任，理想情况下，如果这些数据还没有加载，在你第一次访问的时候，ORM 来加载需要的数据。
NHibernate 具有这种能力，不需要你继承任何的 NHibernate 基类或者实现任何的接口，或者类似的任何东西。那么，它如何工作呢？好，NHibernate 在需要延迟加载的时候通过你的类的代理来完成。那么，什么是代理？在这里，NHibernate 的代理是一种在初始化应用程序的时候自动生成的类型（这仅仅发生在应用程序启动的时候），一种代理类型对应一种没有明确不使用延迟加载的实体类型，代理类型将会派生自你定义的实体类型，然后注入你可能在这种类型上的操作。
让我们通过一个简单的例子来使这件事更加清楚一些，假设你定义了一个 Order 类，除了其他的成员之外，Order 类有像 Employee 和 Customer 的属性。当你加载 Order 实例的时候，你可能并不希望 Employee 属性已经包含了实际的 Employee 实体，类似地还有 Customer 属性，默认情况下，NHibernate 延迟加载每一个实体，除非明确配置为不延迟。所以，当 NHibernate 初始化的时候，它将会知道需要为 Employee 和 Customer 类型动态生成代理，假设相应的代理类型为 EmployeeProxyType 和 CustomerProxyType，实际的类型不是这些名称，但是不影响我们的讨论，现在，设想你获取了一个 Order 对象实例，你不希望 NHibernate 预先加载 Customer 和 Employee 数据，你没有请求 Customer 或者 Employee 数据，所以，现在还没有这些数据，对不对？但是他们也不应该是 null ，对吗？所以，NHibernate 赋予一个 CustomerProxyType 的实例给 Customer 属性，EmployeeProxyType 的实例给 Employee 属性，然后，初始化这两个属性，使其包含标识信息，这样，你就得到了内存中的订单数据。
你可以安全的使用 Order 实例，甚至可以访问 Employee 和 Customer 属性，但是，一旦你访问没有实际数据的代理成员，包括属性和方法，NHibernate 需要确信 Customer 或者 Employee 的数据从数据库已经获取，NHibernate 怎么处理呢？代理将会重写所有你的属性和方法，当其中任何一个被访问的时候，如果数据还没有实际获取，NHibernate 将会加载数据，然后执行原来属性或者方法的实现逻辑，如果数据已经获取，那么，就会直接调用原来的实现逻辑。
这是基本的面向对象，你定义的实体对于 NHibernate 代理来说是一个基类，这些代理需要扩展你定义实体的行为，来完成上述的功能，NHibernate 需要 override 任何的公共成员来确信在适当的时间触发这些行为。现在，有不少的人不喜欢这种要求。首先，认为这是一个主要的性能花费，访问虚拟成员要比访问非虚拟成员费时，然而，这种性能损失非常小，几乎在任何情况下都可以完全忽略不计。这种花费与真正的性能花费完全不能相比，比如数据库访问的花费。另外一个不喜欢的原因是他们不希望派生类 override 他们的任何成员，在某些情况下，这是一个有力的理由，但是，实际上没有价值。有其他的 ORM 实现不需要你的成员是 virtual 的情况下仍然可以延迟加载，但是，这些 ORM 实现经常要求你或者派生自某个特定的基类，或者实现一个或者多个 ORM 使用的接口，在这两种情况下，我认为 NHibernate 的做法对实体的影响远远低于其他的 ORM ，不过，这只是我的意见。
但是，如果你真的不需要成员是 virtual，而且不使用 NHibernate 的延迟加载，你只需要简单地映射你的实体不使用延迟加载即可，你的映射文件应该如下所示：
<class name="OrderLine" table="OrderLine" lazy="false" >
将 lazy 属性设置为 false 将会确信 NHibernate 不会创建你的实例类型的代理类型，你将会得到实际定义的实体类型对象实例，而不会是代理类型的对象实例，这也代表在获得实体对象的时候你将不会得到任何类型的延迟加载。
