Summary of Qualifications

I was born in XXXX, in XX province. I have more than 5 years experience with .NET development. I had participated in many large-scale .Net application design development, which make me  to accumulate a lot of experience in development. I have a deep understand in technology and business. I have very strong learning capability and innovation ability.

Education

·         XXXX.9 – XXXX.7 Master of XXXX, XXXX University of XXXX, Wuhan, China

·         XXXX.9 – XXXX.7  Bachelor of XXXX , China

Work Experience

XXXX.XX – XXXX.XX    XXXX Company

Industry :

Department:

Role:

Responsibility: 

XXXX.XX – XXXX.XX    XXXX Company

Industry :

Department:

Role:

Responsibility: 

The following are the projects I had participated in this company:

·         XXXX
Time Period:
Description：
Technology：
Responsibility：

·         XXXX
Time Period:
Description：
Technology：
Responsibility：

Skill Set:

§         Analyst                      expert                          6 years

§         Oracle                        understanding             1 year

§         SQL Server                expert                         8 years

§         c/C++                         expert             4 years

如果您收到了EDS公司的自动回执邮件，请按以上格式撰写您的英文简历并发送到指定的网页。

• 定义 recipes ，包括定义参数（arguments）, 向导页面（wizards） 和 所执行的操作（actions）
• 定义 Visual Studio 模板文件（Template）。
• 设计 actions 。
• 书写参数类型编辑器和转换器，即editors 和 converters 。
• 定义 T4 模板 (如果一个 action 需要使用 T4 template 生成代码) 。
• 测试 package。
• 绑定 package 安装文件。

一个guidance package 包含下面的部分或者全部的文件:

• Guidance package 配置文件(是一个XML文档,必须)
• Visual Studio 模板文件(可使用VS自动生成,然后对生成的模板再做稍微更改即可)
• T4 模板(以.T4结尾,用于生成代码)
• 一些DLL文件,包括 actions, type editors, value providers和type converters (建议使用单一的DLL)

以下是一份Guidance package 配置文件，其中有注释：

<?xml version="1.0" encoding="utf-8" ?>
<GuidancePackage xmlns="http://schemas.microsoft.com/pag/gax-core"
    Name="这里是Guidance package的名字" 
    Caption="这里是标题"
    Description="这里是描述"
    Guid="51FCD4D0-B90C-4f11-B868-E9D71D8B7746" 
        BindingRecipe="BindingRecipe"
    SchemaVersion="1.0">
    <Recipes>
        <Recipe Name="这里是Recipe 名" Bound="是否有限制可以是true或false" Recurrent="执行后是否重新呈现，可以是true或者false">
            <Caption>这里是Recipe 标题</Caption>
            <Description>这里是Recipe 的描述.</Description>
            <HostData>
                <Icon ID="1046"/>
                <CommandBar Name="这里是该Recipe 可以绑定的位置，可供选择的有Solution，Solution Folder，Solution Add，Solution Folder Add，Project，Project Add，Folder，Item，Web Project，Web Item，Web Folder"/>
            </HostData>         

<GatheringServiceData>
            <Wizard xmlns="http://schemas.microsoft.com/pag/gax-wizards" SchemaVersion="1.0">
                <Pages>
                    <Page>
                        <Title>这里是Page的标题</Title>
                        <LinkTitle>这里是收集参数的向导页面的左侧显示的标题</LinkTitle>
                        <Fields>
                            <Field ValueName="参数名" Label="显示名"  
                                InvalidValueMessage="无效输入时显示的信息.">
                                <Tooltip>提示信息</Tooltip>
                            </Field>                           

                        </Fields>
                    </Page>

                </Pages>
            </Wizard>
        </GatheringServiceData>

<Actions>
                <Action 
                    Name="Action名" 
                    Type="HoLPackage.Actions.HelloWorldAction, HoLPackage" />
            </Actions>
        </Recipe>

</Recipes>
</GuidancePackage>

不过这个定义太抽象了。在SQL Server中，索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。如下图：

非聚簇索引

聚簇索引

聚簇索引与非聚簇索引的本质区别到底是什么？什么时候用聚簇索引，什么时候用非聚簇索引？

这是一个很复杂的问题，很难用三言两语说清楚。我在这里从SQL Server索引优化查询的角度简单谈谈(如果对这方面感兴趣的话，可以读一读微软出版的《Microsoft SQL Server 2000数据库编程》第3单元的数据结构引论以及第6、13、14单元)。

一、索引块与数据块的区别

大家都知道，索引可以提高检索效率，因为它的二叉树结构以及占用空间小，所以访问速度块。让我们来算一道数学题：如果表中的一条记录在磁盘上占用1000字节的话，我们对其中10字节的一个字段建立索引，那么该记录对应的索引块的大小只有10字节。我们知道，SQL Server的最小空间分配单元是“页（Page）”，一个页在磁盘上占用8K空间，那么这一个页可以存储上述记录8条，但可以存储索引800条。现在我们要从一个有8000条记录的表中检索符合某个条件的记录，如果没有索引的话，我们可能需要遍历8000条×1000字节/8K字节=1000个页面才能够找到结果。如果在检索字段上有上述索引的话，那么我们可以在8000条×10字节/8K字节=10个页面中就检索到满足条件的索引块，然后根据索引块上的指针逐一找到结果数据块，这样IO访问量要少的多。

二、索引优化技术

是不是有索引就一定检索的快呢？答案是否。有些时候用索引还不如不用索引快。比如说我们要检索上述表中的所有记录，如果不用索引，需要访问8000条×1000字节/8K字节=1000个页面，如果使用索引的话，首先检索索引，访问8000条×10字节/8K字节=10个页面得到索引检索结果，再根据索引检索结果去对应数据页面，由于是检索所有数据，所以需要再访问8000条×1000字节/8K字节=1000个页面将全部数据读取出来，一共访问了1010个页面，这显然不如不用索引快。

SQL Server内部有一套完整的数据检索优化技术，在上述情况下，SQL Server的查询计划（Search Plan）会自动使用表扫描的方式检索数据而不会使用任何索引。那么SQL Server是怎么知道什么时候用索引，什么时候不用索引的呢？SQL Server除了日常维护数据信息外，还维护着数据统计信息，下图是数据库属性页面的一个截图：

从图中我们可以看到，SQL Server自动维护统计信息，这些统计信息包括数据密度信息以及数据分布信息，这些信息帮助SQL Server决定如何制定查询计划以及查询是是否使用索引以及使用什么样的索引（这里就不再解释它们到底如何帮助SQL Server建立查询计划的了）。我们还是来做个实验。建立一张表：tabTest(ID, unqValue，intValue)，其中ID是整形自动编号主索引，unqValue是uniqueidentifier类型，在上面建立普通索引，intValue 是整形，不建立索引。之所以挂上一个没有索引的intValue字段，就是防止SQL Server使用索引覆盖查询优化技术，这样实验就起不到作用了。向表中录入10000条随机记录，代码如下：

CREATE TABLE [dbo].[tabTest] (
 [ID] [int] IDENTITY (1, 1) NOT NULL ,
 [unqValue] [uniqueidentifier] NOT NULL ,
 [intValue] [int] NOT NULL 
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[tabTest] WITH NOCHECK ADD 
 CONSTRAINT [PK_tabTest] PRIMARY KEY  CLUSTERED 
 (
  [ID]
 )  ON [PRIMARY] 
GO

ALTER TABLE [dbo].[tabTest] ADD 
 CONSTRAINT [DF_tabTest_unqValue] DEFAULT (newid()) FOR [unqValue]
GO

CREATE  INDEX [IX_tabTest_unqValue] ON [dbo].[tabTest]([unqValue]) ON [PRIMARY]
GO

declare @i int
declare @v int

set @i=0
while @i<10000
begin
    set @v=rand()*1000    
    insert into tabTest ([intValue]) values (@v)
    set @i=@i+1
end

然后我们执行两个查询并查看执行计划，如图：（在查询分析器的查询菜单中可以打开查询计划，同时图上第一个查询的GUID是我从数据库中找的，大家做实验的时候可以根据自己数据库中的值来定）：

从图中可以看出，在第一个查询中，SQL Server使用了IX_tabTest_unqValue索引，根据箭头方向，计算机先在索引范围内找，找到后，使用Bookmark Lookup将索引节点映射到数据节点上，最后给出SELECT结果。在第二个查询中，系统直接遍历表给出结果，不过它使用了聚簇索引，为什么呢？不要忘了，聚簇索引的页节点就是数据节点！这样使用聚簇索引会更快一些（不受数据删除、更新留下的存储空洞的影响，直接遍历数据是要跳过这些空洞的）。

下面，我们在SQL Server中将ID字段的聚簇索引更改为非聚簇索引，然后再执行select * from tabTest，这回我们看到的执行计划变成了：

SQL Server没有使用任何索引，而是直接执行了Table Scan，因为只有这样，检索效率才是最高的。

三、聚簇索引与非聚簇索引的本质区别

现在可以讨论聚簇索引与非聚簇索引的本质区别了。正如本文最前面的两个图所示，聚簇索引的叶节点就是数据节点，而非聚簇索引的页节点仍然是索引检点，并保留一个链接指向对应数据块。

还是通过一道数学题来看看它们的区别吧：假设有一8000条记录的表，表中每条记录在磁盘上占用1000字节，如果在一个10字节长的字段上建立非聚簇索引主键，需要二叉树节点16000个（这16000个节点中有8000个叶节点，每个页节点都指向一个数据记录），这样数据将占用8000条×1000字节/8K字节=1000个页面；索引将占用16000个节点×10字节/8K字节=20个页面，共计1020个页面。

同样一张表，如果我们在对应字段上建立聚簇索引主键，由于聚簇索引的页节点就是数据节点，所以索引节点仅有8000个，占用10个页面，数据仍然占有1000个页面。

下面我们看看在执行插入操作时，非聚簇索引的主键为什么比聚簇索引主键要快。主键约束要求主键不能出现重复，那么SQL Server是怎么知道不出现重复的呢？唯一的方法就是检索。对于非聚簇索引，只需要检索20个页面中的16000个节点就知道是否有重复，因为所有主键键值在这16000个索引节点中都包含了。但对于聚簇索引，索引节点仅仅包含了8000个中间节点，至于会不会出现重复必须检索另外1000个页数据节点才知道，那么相当于检索10+1000=1010个页面才知道是否有重复。所以聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。

让我们再来看看数据检索的效率，如果对上述两表进行检索，在使用索引的情况下（有些时候SQL Server执行计划会选择不使用索引，不过我们这里姑且假设一定使用索引），对于聚簇索引检索，我们可能会访问10个索引页面外加1000个数据页面得到结果（实际情况要比这个好），而对于非聚簇索引，系统会从20个页面中找到符合条件的节点，再映射到1000个数据页面上（这也是最糟糕的情况），比较一下，一个访问了1010个页面而另一个访问了1020个页面，可见检索效率差异并不是很大。所以不管非聚簇索引也好还是聚簇索引也好，都适合排序，聚簇索引仅仅比非聚簇索引快一点。

结语

好了，写了半天，手都累了。关于聚簇索引与非聚簇索引效率问题的实验就不做了，感兴趣的话可以自己使用查询分析器对查询计划进行分析。SQL Server是一个很复杂的系统，尤其是索引以及查询优化技术，Oracle就更复杂了。了解索引以及查询背后的事情不是什么坏事，它可以帮助我们更为深刻的了解我们的系统。

这套工具旨在简化将可重用的代码集成到应用程序的过程，使架构师能将通常需手动执行的一系列开发工作自动化起来。 使用此工具，还能确保重复性的、易出错的开发工作以合理、一致的方式完成，并能缩短软件开发时间。

安装Guidance Automation Toolkit

使用Guidance Automation Toolkit，需要先安装一个叫做Guidance Automation Extensions 的runtime组件，然后下载并安装Guidance Automation Toolkit。更多信息，请参见Guidance Automation Toolkit and Guidance Automation Extensions Download.

了解Guidance Automation Toolkit

Guidance Automation Toolkit 由以下一系列的元素组成，这些元素共同工作以实现自动化功能：

·         Recipes: Recipe 将开发人员通常需按照一系列指示手动执行的开发动作自动化起来。你可以通过使用Recipe来确保重复性的、易出错的开发工作以合理、一致的方式完成，并能够简化复杂或重复性的开发工作。Recipe可以运行在某个特定的解决方案元素上，或运行在一组有共同特点的解决方案元素上（例如，所有的C#项目）。

·         Actions：Action是一个原子单位的操作，以一定的顺序被Recipe调用。这个顺序在Recipe的定义中指定。一个Action首先接受一定的输入，输入既可以来自Recipe收集到的参数，也可以是前面的Action执行完的输出结果。每个Recipe包含的Action在Recipe的定义中指定。

·         Text Template Transformation Templates：一个Text Template Transformation Template由文本和脚本组成。脚本用VB或C#写，运行的时候将会返回一个字符串，且这个字符串会被直接插入到Template输出流中。Guidance Automation Toolkit中的Text Template Transformation 引擎对Template进行了扩展。

·         Wizards：Wizard用来收集Recipe的参数的值。每个Recipe可以有一个与之相关的Wizard，Wizard通过一个或多个页面来引导开发人员进行参数值的收集。

·         Type Converters：Type Converter验证收集到的值的正确性，并将这些值由用户界面表达形式转换为类型表达形式。

·         Visual Studio Templates：Visual Studio Template是以XML格式构成的文件，Visual Studio使用Template文件来创建解决方案或向已有的解决方案中添加一个或多个项目。Visual Studio template引擎扩展了这些template。在Guidance Automation Toolkit中，可以将Visual Studio template和Recipe关联起来。关联意味着，当一个Template被打开时，Wizard Extension会通知Recipe让Wizard收集参数值。在Template被打开后，通知Recipe执行可能有的Action，对template创建的解决方案项目进行进一步的转换操作。

以上的每个元素被收集后和配置文件一同放入Guidance Package中，作为一个单元进行安装。这些Guidance Package在Visual Studio 2005里可以用Guidance Package Manager进行管理。当Guidance Package完成安装并在解决方案中Enable之后，就可以运行Recipe来执行特定的开发工作了。


GAT&GAX这是两个不错的架构师工具,一般来说,由架构师制作一些Recipes供开发人员使用。本人近期正在学习ＧＡＴ的开发，并准备做一些Recipes，希望希望学习的朋友一起交流。

下面是开发人员想要对URL有更大的灵活性的最常见的场景：

1) 处理这样的情形：你要更改你的web应用中网页的结构，但你同时也要确保在你移动网页后，那些被人收藏的老URL不会成为死链接。重写URL允许你透明地将请求转交到新的网页地址而不出错。

2) 在象Google，Yahoo 和 Live 这样的搜索引擎中提高你网站上网页的搜索相关性。具体地来说，URL重写经常能使你在你网站上网页的URL里更加容易地嵌入关键词，这么做往往会增加别人点击你的链接的机会。从使用查询字符串参数到使用完全限定(fully qualified)的URL也能在某些情形下提高你在搜索引擎结果中的优先顺序。使用强制referring链接使用同样的大小写(same case)和URL入口(譬如，使用weblogs.asp.net/scottgu 而不是 weblogs.asp.net/scottgu/default.aspx)的技术也能避免因跨越多个URL而造成的网页排名(pagerank)的降低(avoid diluting your pagerank across multiple URLs)，从而增加你的搜索结果。

在一个搜索引擎日渐驱动网站访问量的世界里，在你的网页排名上稍微得到一些提高就能给你的业务带来不错的投资回报(ROI)。逐渐地，这驱使开发人员使用URL重写以及其他SEO(搜索引擎优化 )技术来优化网站(注，SEO是个步调很快的空间，增加你的搜索相关性的建议月月在演变)。想了解一些关于搜索引擎优化方面好的建议的话，我建议你阅读一下《SSW Rules to Better Google Rankings (SSW的提高Google排名之要领)》，以及MarketPosition关于《how URLs can affect top search engine ranking (URL会如何影响顶级搜索引擎排名)》的文章。

例程的URL重写场景

为这个博客贴子起见，我将假设我们将在一个应用里建造一套电子商务的产品目录网页，产品是按种类来组织的(譬如，图书，录像，CD，DVD等等)。

让我们假定一开始我们有个网页叫Products.aspx，通过查询字符串参数接受一个类别名称，相应地过滤显示的产品。与这个Products.aspx网页对应类别的URL看上去象这样：

但我们不想使用查询字符串来呈示每个类别，我们想修改应用，让每个产品类别对搜索引擎来说看上去象是一个独特的URL，并且在实际的URL中嵌入关键词(而不是通过查询字符串参数)。我们将在这个博客帖子剩下来的篇幅里，讨论一下达成这个目的我们可以采取的4种不同方法。

方法一：使用Request.PathInfo 参数而不是查询字符串

我将示范的第一个方法根本不使用URL重写，而是使用ASP.NET中不太为人所知的一个特性，Request的PathInfo属性。为帮助解释这个属性的有用之处，考虑一下我们电子商店下面这些URL的情形：

你会在上面这些URL中注意到的一个东西是，他们不再含有查询字符串值，取而代之的是，类别参数的值是附加到URL上的，是以Products.aspx网页处理器名称之后的/参数 值的方式出现的。然后，一个自动化的搜索引擎爬虫(search engine crawler)会把这些URL解释成三个不同的URL，而不是一个URL带有三个不同的输入值 (搜索引擎是不理会文件扩展名的，只把它当作URL中的另一个字符而已)。

你也许很想知道怎么在ASP.NET中处理这个附加的参数的情形。好消息是，这非常简单。只要使用Request的PathInfo属性就可以了，该属性返回URL中紧随 products.aspx 后面的那部分内容。所以，对上面这些URL， Request.PathInfo会分别返回 “/Books”， “/DVDs”，和 “/CDs”(万一你想知道的话， Request的Path 属性返回“/products.aspx” )。

然后，你可以轻易地编写一个函数来获取产品类别，象这样(下面这个函数去除前面的斜杠字符，只返回“Books”，“DVDs”，或 “CDs”)：

样例下载：我建立的一个展示这个技术的样例应用可以在这里下载。这个样例和这个技术的很好的地方在于，为部署使用这个方法的ASP.NET应用，不需作任何服务器配置改动。在共享主机的环境里，这个技术也行之有效。

方法二：使用HttpModule实现URL重写

上述Request.PathInfo技术的替换方法是，利用ASP.NET提供的HttpContext.RewritePath方法。这个方法允许开发人员动态地重写收到的URL的处理路径，然后让ASP.NET使用刚重写过后的路径来继续执行请求。

譬如，我们可以选择向大众呈示下列URL：

在外界看来，网站上有三个单独的网页(对搜索爬虫而言，这看上去很棒)。通过使用 HttpContext的RewritePath方法，我们可以在这些请求刚进入服务器时，动态地把收到的URL重写成单个Products.aspx网页接受一个查询字符串的类别名称或者PathInfo参数。譬如，我们可以使用Global.asax中的Application_BeginRequest事件，来这么做：

手工编写象上面这样的编码的坏处是，很枯燥乏味，而且容易犯错。我建议你别自己写，而是使用网上现成的HttpModule来完成这项工作。这有几个你现在就可以下载和使用的免费的HttpModule：

• UrlRewriter.net
• UrlRewriting.net

这些模块允许你用声明的方式在你应用的web.config文件里表达匹配规则。譬如，在你应用的web.config文件里使用UrlRewriter.Net模块来把上面的那些URL映射到单个Products.aspx页上，我们只要把这个web.config文件添加到我们的应用里去就可以了(不用任何编码)：

上面的HttpModule URL重写模块还支持正则表达式和URL模式匹配(以避免你在web.config 文件里硬写每个URL)。所以，不用写死类别名称，你可以象下面这样重写匹配规则，把类别名称动态地从任何/products/[类别].aspx组合的URL里取出来：

这使得你的编码极其干净，并且扩展性非常之好。

样例下载：我建立的一个使用UrlRewriter.Net模块展示这个技术的样例应用可以在这里下载。

这个样例和这个技术的很好的地方在于，为部署使用这个方法的ASP.NET应用，不需作任何服务器配置改动。在设置为中等信任安全等级(medium trust)的共享主机的环境里，这个技术也行之有效 (只要把文件FTP/XCOPY到远程服务器就可以了，不需要安装)。

方法三：在IIS7中使用HttpModule 实现无扩展名的URL重写

上述的HttpModule方法在你要重写的URL含有.aspx 扩展名或者包含另一个被设置为ASP.NET处理的扩展名的情形下一切都工作。你这么做的话，不需要任何特定的服务器配置，你只要把你的应用拷贝到远程服务器，它会正常工作的。

但有的时候，你要重写的URL要么拥有一个不为ASP.NET处理的文件扩展名(譬如， .jpg， .gif， 或 .htm)，要么根本没有扩展名。譬如，我们也许要把这些URL呈示成公开的产品目录网页(注意，它们没有 .aspx 扩展名)：

在 IIS5 和 IIS6 中，使用ASP.NET处理上面这样的URL不是很容易。 IIS 5/6 使得在ISAPI扩展(ASP.NET就是这样一个扩展)里非常难以重写这些类型的URLS。你需要做的是使用ISAPI过滤器在IIS请求管道(request pipeline)的较早期实现重写。我将在下面的第四个方法里示范如何在 IIS5/6 实现这样的重写。

但好消息是， IIS 7.0使得处理这类情形容易之极。你现在可以在 IIS 请求管道的任何地方执行一个HttpModule，这意味着你可以使用上面的URLRewriter 模块 来处理和重写无扩展名的URL(甚至是带有 .asp，.php，或 .jsp 扩展名的URL)。下面示范了你在IIS7中该如何配置：

注意一下<system.webServer>内<modules>部分设置为true的runAllManagedModulesForAllRequests属性。这个属性确保来自Intelligencia的UrlRewriter.Net模块(是在IIS7正式发布前编写的)，会被调用，有机会重写到服务器的所有URL请求(包括文件夹)。上面的web.config文件非常酷之处在于：

1) 它在任何IIS7机器上都会工作，你不需要管理员在远程主机上启用任何东西，它也能在设置为中等信任安全等级(medium trust)的共享主机的环境场景下工作。

2) 因为我在<httpModules>和 IIS7 的<modules> 部分同时配置了UrlRewriter，我既能在 VS内置的web服务器(即Cassini)中，也能在IIS7下使用同样的URL重写规则。两者完全支持无扩展名的URL重写。这使得测试和开发非常容易。

IIS 7.0 将在今年的晚些时候作为Windows Longhorn服务器的一部分发布，将在几个星期内随Beta3版本的发布支持go-live许可。由于添加到IIS7中的所有的新宿主(hosting)特性，我们预期主机供应商将会非常快地开始积极提供IIS7账号，这意味着你应该很快就可以开始利用上述的无扩展名的URL重写支持。我们将在 IIS7 RTM 时段里发布一个为微软所支持的URL重写模块，该模板是免费的，你可以在IIS7上使用，并且这模块将对你web服务器上的所有内容的高级URL重写场景提供很好的支持。

样例下载：我建立的一个使用IIS7和UrlRewriter.Net模块展示无扩展名URL重写技术的样例应用可以在这里下载。

方法四：在IIS5和IIS6中使用 ISAPIRewrite 来实现无扩展名的URL重写

如果你不想等到IIS7出来才利用无扩展名的URL重写，那么你最好的措施是使用ISAPI过滤器来重写URL。我知道有2个ISAPI过滤器方案，你也许要去看一下：

• Helicon Tech's ISAPI Rewrite: 他们提供一个99美元(可免费试用30天)的ISAPI URL重写产品完整版，以及一个免费的轻量级版本。
• Ionic's ISAPI Rewrite: 这可以免费下载(源码和可执行文件都可以下载)

我没亲手用过上面的产品，虽然我听过到对这2个产品的好评。Scott Hanselman和 Jeff Atwood 最近都写了精彩的博客贴子讲述使用这些产品的体验，同时提供了一些如何在这些产品中配置匹配规则的例子。Helicon Tech的ISAPI Rewrite的规则使用跟 Apache的mod_rewrite同样的句法，譬如(取自Jeff的博客贴子)：

一定要去读一下Scott和Jeff的贴子以了解这些ISAPI 模块的详情，以及你都能用它们做些什么。

注：使用ISAPI过滤器的一个坏处是，共享主机环境一般不允许你安装这样的组件，所以你要用它们的话，你要么需要一个专用的虚拟主机服务器，要么需要一个专用的主机服务器。但，如果你有一个主机计划允许你安装ISAPI的话，这会在IIS5/6下会提供最大的灵活性，让你过渡到IIS7推出为止。

在URL重写里处理ASP.NET PostBack

大家在使用ASP.NET和重写URL时经常遇到的一个疑难杂症跟处理postback场景有关。具体地来说，当你在一个网页上放置一个 <form runat="server"> 控件时，ASP.NET 会自动地默认输出标识的action属性指向当前所在页面。当使用URL重写时，会出现这样的问题，<form> 控件显示的URL不是原先请求的URL(譬如，/products/books)，而是重写过后的URL(譬如，/products.aspx?category=books)。这意味着，当你做一个postback到服务器时，URL不再是你原先干净利落的那个了。

在 ASP.NET 1.0 和1.1 中，大家经常诉诸于继承<form> 控件生成他们自己的控件，来正确地输出要使用的action属性。虽然这可以工作，但结果有点乱，因为这意味着你需要更新你所有的页面来使用这个另外的表单控件，而且有时在Visual Studio所见即所得设计器里也会遇上问题。

好消息是，在ASP.NET 2.0中，有个比较干净的诀窍你可以用来重写<form>控件的action属性。具体地来说，你可利用新的ASP.NET 2.0控件适配器扩展架构来定制控件的输出，用你提供的值来覆盖action属性的值。这不要求在你的.aspx页面里做任何编码改动，而只要在你的/app_browsers文件夹里添加一个.browser文件，注册使用一个控件适配类即可输出新的action属性。

继前面微软公司发布Windows Communication Foundation (WCF)和Windows CardSpace的示例程序之后，微软今天又发布了WF的教程和大量示例，对于学习WF的朋友来说，是一份很好的学习资料。下载包括教程和示例两个压缩包，在示例部分包括如下的Application：

l         OrderingStateMachine

l         OutlookWorkflowWizard

l         SpeechApplication

l         TerminationTrackingService

l         TrackingProfileDesigner

l         WorkflowMonitor

l         WorkflowReflectionUtility

Microsoft曾经大肆鼓吹Software Factory，而在SOA(Service-Oriented Architecture)在大型项目开发中崭露头角时，我们就不能忽略Web Service Software Factory，尤其是在Microsoft重磅推出WCF(Windows Communication Foundation)的前提下。

Web Service Software Factory通常简称为Service Factory，它不仅仅是一种软件设计思想，准确地说它集成了开发工具、模式、设计向导、文档以及源代码。通过它，能够帮助开发者通过架构设计、模式以及WCF等快速地创建Web Service。Service Factory的架构如图所示：

主要内容包含：
1、设计ASMX和WCF消息和服务接口；
2、建立统一的异常处理机制；
3、为领域模型创建业务实体对象；
4、完成业务实体对象与消息的转换；
5、设计、创建、调用数据访问层；
6、服务的实现、配置与安全；
7、项目向WCF的迁移；
8、为WCF服务实施安全；
9、提供消息的验证；

有关Service Factory的详细情况可以访问http://msdn.com/servicefactory。

为了更好地帮助开发者理解Service Factory，Microsoft还提供了Service Factory Hands-on Lab。它提供了一套完整的练习，分别包括：
练习1：创建解决方案；
练习2：创建数据类型；
练习3：创建消息类型；
练习4：创建服务操作（Service Operation，类似于Web Service的Web方法）；
练习5：创建业务实体对象；
练习6：完成业务实体对象与消息的转换；
练习7：创建存储过程；
练习8：创建数据访问类；
练习9：调用数据访问层；
练习10：测试与客户端调用；

Service Factory Hands-on Lab是以一个实际的例子来开展的，其目的是为一个虚拟的酒业零售商Coho Winery提供会员服务。通过该练习，你可以从中体会到分层式架构设计、SOA的“服务自治”、基于消息的分布式处理系统、WCF、数据与消息以及单元测试、设计模式等诸多具有价值的技术与思想。

如欲了解Service Factory Hands-on Lab，并下载相关工具与代码，请访问What you'll see inside the lab 。此外，要了解与关注Service Factory，可以访问http://www.codeplex.com/servicefactory。

1、一个网页被多次引用，则它可能是很重要的；
一个网页虽然没有被多次引用，但是被重要的网页引用，则它也可能是很重要的；一个网页的重要性被平均的传递到它所引用的网页。这种重要的网页称为权威（Authoritive）网页。

2、假定用户一开始随机的访问网页集合中的一个网页，然后跟随网页的链接向前浏览网页，不回退浏览，那么浏览下一个网页的概率就是被浏览网页的PageRank值
影响PR值的因素
PR值体现为从0到10的11个数值，在Google的工具栏上以一条横向绿色柱状图显示，0级情况下呈白色。它是针对网页而不是网站，因此一个网站的首页和内页往往有着迥然不同的PR值。由于Google市场拓展进程的原因，中文网页的PR值整体上低于英文网页。对中文网站来说，拥有3级PR是基础， 4级PR算达标，5级PR可谓良好，而6、7级PR就算相当优秀的网站。当然，由于PR最直接的影响因素是来自链接，因此这种评级并不代表内容的级别水准，网站内容质量对PR的影响是间接的、长期的。根据PR值的算法原理，可知影响一个网站（首页）PR值的因素主要包括：

1、网站的导入链接质量：
根据前文对高质量导入链接的分析，则获得高PR值需要获得来自以下网站的链接：

◆ 加入搜索引擎分类目录与已经加入目录的网站交换链接
◆ 获得来自PR值不低于4并与你的主题相关或互补的网站的链接
◆ 你的链接出现在流量大、知名度高、频繁更新的重要网站上（如新闻源）
◆ 与你交换链接的网站具有很少导出链接
◆ 与内容质量高的网站链接（PR值上升潜力大）

2、 导出链接数量：
根据PR计算原理，由于"一个网页的重要性被平均的传递到它所引用的网页"，因此反过来看，一个页面内过多的导出链接将潜在引起该页PR值的流失。但从内容的角度看，适当数量的与主题有关联的导出链接给搜索引擎带来良好的印象。因此，一个页面，尤其是首页的导出链接数量的把握，应该兼顾到PR值和关键词内容二者之间的平衡，即控制导出链接数量，以不超过10个为宜。

3、搜索引擎收录一个网站的页面数量
在探讨SEO的时候，人们过多关注核心关键词排名以及首页的表现情况，却往往忽略了一个极其重要的问题：即搜索引擎对一个网站收录的页面数量。后者在SEO中也有着极其重要的意义。一个用核心关键词查询排名不佳的网站，可能由于被抓取大量网页而在用户使用其它关键词查询时，内页获得前三甲排名。由于用户搜索时使用的关键词具有分散性，使得这种情况往往给网站带来极大访问量。

正因为收录页面的数量直接影响访问量，因此对PR值的影响也是很大的。被收录页面越多，主页PR越高。不过需要强调的是，此处所指的数量是指被收录数与网站页面总数的比值，而不是收录页面的绝对数值。比如一个拥有50个页面的网站被收录了10个页面，网站的被收录比值是1/5，一个拥有5000个页面的网站被收录了500个页面，比值是1/10，结果是收录10个页面比收录500个页面的网站还更具排名优势。但对各个搜索引擎来说，究竟达到多大的比值算是良好，目前还没有相关的数据。

附：查询网站收录页面数量：在搜索引擎中输入：site:www.kuziyuan.com（如果输入：site:admin5.com，则获得的是在admin5.com域名下所有二级域名的网页数量）。

第一部分：域名和主机对SEO的影响
域名与主机是网站的基础，商业网站选择域名与主机尤其应注重形象和质量，为网络营销开展打好坚实基础。同时，选择好域名与主机也是搜索引擎优化开始的第一步。

域名选择与SEO
域名与IP：每一个网站的域名对应一个IP地址，IP 地址是在网络上分配给每台计算机或网络设备的数字标识。域名必须经过域名服务器（DNS）进行解析，转换成数字IP，才能让计算机理解辨认，如：219.136.248.149 大部分中小企业网站都存放在由一台服务器划分出来的若干虚拟主机上，由多个网站共享一台服务器和IP地址，一些WEB服务器中有成百上千个域名共享一个IP地址的情况。这样对站长来说成本较低，但对网站的搜索引擎排名带来以下潜在风险：

1、共享主机的其他网站如果被搜索引擎惩罚，将或多或少波及你的网站。如果同一IP下有一个网站作弊，那么我们的