这已经是系列 的第13篇了，实际上到现在为止您应该对BlogEngine.Net的整体设计有了一定的把握，对部分实现细节有了比较深刻的认识，在阅读 BlogEngine.Net时希望坚持到最后，并把握住宏观，深入到微观。本文将详细介绍BlogEngine.Net中的HttpHandlers与 HttpModules，主要说明它们要实现的功能以及如何使用，并对几个必要的HttpHandler或HttpModule进行比较细致的分析。

     HttpHandler和HttpModule

     对于HttpHandler和HttpModule我这里不想多说了， 因为关于它们讲解的文章实在太多太多了，大家可以在博客园的找找看中直接输入“HttpHandler和HttpModule”就可以找到。我的理解就是 一个HttpHandler要实现IHttpHandler接口，主要是对某个请求进行直接处理，一个HttpModule要实现IHttpModule 接口，主要是在HttpApplication的生命周期的事件中对请求和响应进行过滤。它们都可以在Web.config文件中进行配置。

     BlogEngine.Net中的HttpHandler

     BlogEngine.Net中的HttpHandler都在BlogEngine.Core.Web.HttpHandlers空间下（除了MetaWeblogHandler，已经讲过，这里就不包含它了），通过Web.config我们可以看到它们的映射关系:

HttpHandlers映射表
<httpHandlers>
    <add verb="*" path="file.axd" type="BlogEngine.Core.Web.HttpHandlers.FileHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="image.axd" type="BlogEngine.Core.Web.HttpHandlers.ImageHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="syndication.axd" type="BlogEngine.Core.Web.HttpHandlers.SyndicationHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="sitemap.axd" type="BlogEngine.Core.Web.HttpHandlers.SiteMap, BlogEngine.Core" validate="false"/>
    <add verb="*" path="trackback.axd" type="BlogEngine.Core.Web.HttpHandlers.TrackbackHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="pingback.axd" type="BlogEngine.Core.Web.HttpHandlers.PingbackHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="opensearch.axd" type="BlogEngine.Core.Web.HttpHandlers.OpenSearchHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="metaweblog.axd" type="BlogEngine.Core.API.MetaWeblog.MetaWeblogHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="rsd.axd" type="BlogEngine.Core.Web.HttpHandlers.RsdHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="css.axd" type="BlogEngine.Core.Web.HttpHandlers.CssHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="js.axd" type="BlogEngine.Core.Web.HttpHandlers.JavaScriptHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="rating.axd" type="BlogEngine.Core.Web.HttpHandlers.RatingHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="opml.axd" type="BlogEngine.Core.Web.HttpHandlers.OpmlHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="blogml.axd" type="BlogEngine.Core.Web.HttpHandlers.BlogMLExportHandler, BlogEngine.Core" validate="false"/>
    <add verb="*" path="sioc.axd" type="BlogEngine.Core.Web.HttpHandlers.Sioc, BlogEngine.Core" validate="false"/>
    <add verb="*" path="apml.axd" type="BlogEngine.Core.Web.HttpHandlers.Apml, BlogEngine.Core" validate="false"/>
    <add verb="*" path="foaf*.axd" type="BlogEngine.Core.Web.HttpHandlers.Foaf, BlogEngine.Core" validate="false"/>
</httpHandlers>

下面对它们进行一一描述：

FileHandler：主要完成对于一些物理文件的请求，例如在文章中插入的文件资源的请求就由它来处理。它的实现比较简单，就直接去磁盘的文件保存目录中读取，我们只要留意一下SetContentType就行了。

ImageHandler：与FileHandler类似，不过它处理的是图片。与FileHandler分开的原因主要就是图片需要在页面上展现（ContentType必须给浏览器讲清楚或采用默认）。

SyndicationHandler：它比较复杂，主要完成各种订阅需求的处理，需要结合 SyndicationFormat（格式枚举）和SyndicationGenerator（按照SyndicationFormat的格式生成 XML）一起使用。我们可以看一下它的实现过程，首先根据请求的查询字符串生成标题，格式，列表（GenerateItemList使用了Search 等）,使用CleanList进行了一个过滤，分页处理，SetHeader，最后使用SyndicationGenerator的WriteFeed进 行了输出。这里考虑的情况比较多，但是BlogEngine.Net使用的分割方法很好的解决了复杂的订阅问题，值得研究一下。

SiteMap：网站地图，可以给一些搜索引擎提供更好的搜索信息，以XML格式将一些文章等页面的链接输出。

TrackbackHandler：接收Trackback信息的处理，前文已经讲过，这里不多说了。

PingbackHandler：接收Pingback信息的处理，前文已经讲过，这里也不多说了。

OpenSearchHandler：提供公开搜索处理，前文已经讲过，这里也不多说了。

RsdHandler：这个处理器很有用，它完成将BlogEngine.Net中的一些公开的接口等信息发布出去，类似WebService的WSDL文件。

CssHandler：主要处理了页面中的Css文件的压缩，上文中讲述BlogBasePage中提及过。处理器的实现很值得关注，压缩可以使用gzip或deflate两种格式，

经典的压缩处理
 1private const string GZIP = "gzip";
 2private const string DEFLATE = "deflate";
 3
 4private static void Compress(HttpContext context)
 5{
 6    if (context.Request.UserAgent != null && context.Request.UserAgent.Contains("MSIE 6"))
 7        return;
 8
 9    if (IsEncodingAccepted(GZIP))
10    {
11        context.Response.Filter = new GZipStream(context.Response.Filter, CompressionMode.Compress);
12        SetEncoding(GZIP);
13    }
14    else if (IsEncodingAccepted(DEFLATE))
15    {
16        context.Response.Filter = new DeflateStream(context.Response.Filter, CompressionMode.Compress);
17        SetEncoding(DEFLATE);
18    }
19}

并提供了一些事件供外界Hookup处理。压缩之前去掉空格等字符，分为从本地获得文件和从远程使用WebClient下载文件。并使用了缓存。

JavaScriptHandler：主要处理页面中引用的脚本的压缩，与Css处理方式类似。注意StripWhitespace的处理与Css的不同。

RatingHandler：主要完成给Post打分的功能，记得上文中有部分涉及到，从PostViewBase中的Rating可以看出，这个请求实际上是通过Ajax发送过来的。

OpmlHandler：获得OPML列表文件,类似收藏文章的列表。

BlogMLExportHandler：BlogEngine.Net中的文章导出处理，以前的文章讲过。

Sioc、Foaf、Apml的注释都是“Based on John Dyer's (http://johndyer.name/) extension.”，这个应该是对于某个标准XML的输出吧，主要提供了本博客系统中的一些公开的信息。关于它们不做太多的研究，我想这并不影响我们 对BlogEngine.Net的研究。

     实际上这些HttpHandlers的请求链接很多都是在BlogBasePage加入到Html的Head中的，或者给浏览器使用，或者给搜索引擎使用。

     BlogEngine.Net中的HttpModule

     BlogEngine.Net中的HttpModule都在BlogEngine.Core.Web.HttpModules空间下,通过Web.config我们可以看到它们的映射关系:

httpModules映射表
<httpModules>
    <add name="WwwSubDomainModule" type="BlogEngine.Core.Web.HttpModules.WwwSubDomainModule, BlogEngine.Core"/>
    <add name="UrlRewrite" type="BlogEngine.Core.Web.HttpModules.UrlRewrite, BlogEngine.Core"/>
    <add name="CompressionModule" type="BlogEngine.Core.Web.HttpModules.CompressionModule, BlogEngine.Core"/>
    <add name="ReferrerModule" type="BlogEngine.Core.Web.HttpModules.ReferrerModule, BlogEngine.Core"/>
    <!–Remove the default ASP.NET modules we don't need–>
    <remove name="PassportAuthentication"/>
    <remove name="Profile"/>
    <remove name="AnonymousIdentification"/>
</httpModules>

请注意它们的注册顺序，因为WwwSubDomainModule和UrlRewrite都Hookup了HttpApplication的BeginRequest事件。下面对它们进行一一描述：

WwwSubDomainModule：Hookup了HttpApplication的BeginRequest事件，主要是对请求的URL中的"www"的处理以得到绝对的链接。

UrlRewrite：Hookup了HttpApplication的BeginRequest事 件，对一些URL的重写，实际上WwwSubDomainModule和UrlRewrite都是在处理URL，我们在看BlogEngine.Net中 的源代码时多留意一下它的URL，包括Post中的各种链接的URL等，注意区分它们都是做什么用的。

ReferrerModule：主要是对于请求的Referrer进行统计，纪录这些请求都是从哪里发送来的，提供了相应的事件供外部Hookup，注意IsSpam的实现和对于纪录日志使用了新线程来异步完成。

CompressionModule：一个Page页面的压缩处理模块，同样根据请求来判断是使用 gzip还是deflate，对于页面中链接的WebResource也是用WebResourceFilter进行了过滤处 理，WebResourceFilter实现了Stream，

WebResourceFilter的Write方法
 1public override void Write(byte[] buffer, int offset, int count)
 2{
 3    byte[] data = new byte[count];
 4    Buffer.BlockCopy(buffer, offset, data, 0, count);
 5    string html = System.Text.Encoding.Default.GetString(buffer);
 6
 7    Regex regex = new Regex("<script\\s*src=\"((?=[^\"]*webresource.axd)[^\"]*)\"\\s*type=\"text/JavaScript\"[^>]*>[^<]*(?:</script>)?", RegexOptions.IgnoreCase);
 8    foreach (Match match in regex.Matches(html))
 9    {
10        string relative = match.Groups[1].Value;
11        string absolute = HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Authority);
12        html = html.Replace(relative, Utils.RelativeWebRoot + "js.axd?path=" + HttpUtility.UrlEncode(absolute + relative));
13    }
14
15    byte[] outdata = System.Text.Encoding.Default.GetBytes(html);
16    _sink.Write(outdata, 0, outdata.GetLength(0));
17}

在重写的Write中主要是将webresource.axd转交给了JavaScriptHandler处理以达到压缩的目的。注意它是在PreRequestHandlerExecute中Hookup的，都是给Response提供的流过滤器。

     总结

     由于篇幅所限，对于BlogEngine.Net中一些 HttpHandlers和HttpModules我并没有作更多的深入讨论，这里只是提供给大家一个学习指南，希望有所帮助。 BlogEngine.Net中大量使用了正则匹配，Url处理，压缩，缓存等都是比较通用的，值得我们关注与学习。

     通用的处理方法值得我们去收藏

     上一篇:BlogEngine.Net架构与源代码分析系列part12：页面共同的基类——BlogBasePage

     返回到目录

     上一篇文章我 向大家展示了BlogEngine.Net中Theme的原理和一些开发规范，里面有很多内容和这篇文章有着联系，建议大家这两篇文章结合在一起看，这样 效果会更好。在这篇文章中我主要向大家说明BlogBasePage，PostViewBase，CommentViewBase这三个类的内部实现上的 一些技巧以及它们与页面，文章和评论之间是如何组织在一起的，希望对大家阅读这部分代码有帮助。

     认识一下它们

     BlogBasePage，PostViewBase，CommentViewBase它们都是一些元素的基类，首先把这些元素定义成基类，然后使用继承的方式实现我认为主要有以下好处：

1.代码复用会得到提升，对于一些大量的同样操作都可以放在基类中，子类直接可以继承使用。

2.职责清晰，例如在Theme中的CommentView.ascx直接继承CommentViewBase就行了，CommentView.ascx只是来处理将Comment如何展现的问题。

3.规范化，这是继承带来的一个很重要的好处，因为子类就是一个父类，只要它是就可以使用。

BlogBasePage：Web站点的根目录下的每一个页面都是从它继承而来，BlogBasePage继承自Page。而页面不是直接从Page继承而来。
PostViewBase：是一个Post显示功能部分的基类，themes中每个主题的PostView.ascx都是直接从它继承而来，PostViewBase继承自UserControl。
CommentViewBase：是一个Comment显示功能部分的基类，themes中每个主题的CommentView.ascx都是直接从它继承而来，CommentViewBase继承自UserControl。

     实现分析

     BlogBasePage到底都做了些什么？

OnPreInit中主要完成根据BlogSetting中的Theme找到相应的页面的Master文件（包括主题选择时的预览判断），此外还处理了Post的删除。
OnLoad中做得事情很多，主要是在head中加入一些资源引用（包括SIOC，APML，FOAF等），实际上就是当我们打开页面查看源代码看到 head中多如牛毛的link。还有增加一些脚本的全局变量，增加BlogSetting中的自定义Head的html，增加track脚本，增加脚本引 用（通过JavaScriptHandler来实现），增加样式（注意css的压缩是通过CssHandler实现的）。
OnPreRenderComplete中完成了标题的设置。
OnError中还对使用Comment的恶意攻击做了处理。

     PostViewBase到底都做了些什么？

PostViewBase是一个用户控件，主要是显示一个Post，内部除了一些Post属性 外，还有CommentFeed（通过SyndicationHandler处理），增加分类链接，增加Tag链接，增加管理链接，增加评分的脚本来给文 章评分等。此外在Page_Load还对加入内容中的一个自定义的控件标签进行了特殊的处理，这种格式如：[UserControl:~/path /usercontrol.ascx]，使用一个正则来判断，如果内容中有这种标签，那么内容显示时使用加载的控件来代替。

     CommentViewBase到底都做了些什么？

CommentViewBase是一个用户控件，主要是显示一个Comment，内部除了Comment和Post属性外，还有内容，管理链接，国旗显示，Gravatar显示等。请大家留意一下后面的两个图片的显示处理。

     了解了这些，上一篇文章中讲述的Theme中的几个必要文件的数据显示问题就清晰多了吧。

     页面的继承与组织关系

     这部分没有什么原理性的东西，只是帮助大家快速阅读代码而做的一个文件的介绍。

login.aspx：继承BlogBasePage，完成登录，注销，修改密码等与登录有关的用户接口。
default.aspx：继承BlogBasePage，内部使用PostList.ascx用户控件完成文章的列表显示接口。
search.aspx：继承BlogBasePage，用一个repeater显示搜索结果，这个以前提及过。
archive.aspx：继承BlogBasePage，对文章的归档显示，注意它的归档的处理过程。
contact.aspx：继承BlogBasePage，主要是完成阅读者给文章的发布者发送邮件。注意它还实现了ICallbackEventHandler，来完成ajax回调提交。
error404.aspx：继承BlogBasePage，404错误转向。
page.aspx：继承BlogBasePage，完成删除Page，显示Page（注意对注入控件显示的处理和与Post区别）。
post.aspx：继承BlogBasePage，完成文章的显示，使用User controls/CommentView.ascx来完成评论列表的显示和评论的提交。Page_Init中动态加载PostViewBase，处理了 “上一篇”和“下一篇”等导航链接(需要Post类本身的支持)，phRDF完成了Trackback的接收（以前文章提及过）。
对于Theme中的文件上文已经讲过，这里就不再多说。
对于admin/Pages中的这些管理页面都是直接继承自Page，Master为admin1.master，在Web.config中定义了访问权限等，这主要是实现了前端页面和后台管理的分开处理。
blog.js是BlogEngine.Net的所有脚本文件，里面封装Ajax处理（例如回调，评论的在线浏览等）。

     总结

     像BlogEngine.Net这种将几乎所有页面的Page再进行一下自定义的封 装的处理方式在很多项目中都会得到应用，这一点我觉得很好。对于注入控件的处理方式也值得我们去学习。这种注入控件我想主要是完成一些外部资源的引入问题 的，把文章或Page的显示交给这个用户控件来处理会很灵活。

     麻雀虽小，五脏俱全

     上一篇:BlogEngine.Net架构与源代码分析系列part11：开发扩展（下）——自定义Theme

     返回到目录

     个性化的主题是一个完善的 Blog系统中所必备的，同时也是一个亮点。在这篇文章里我将给大家展示一下BlogEngine.Net的第三个开发特性，那就是自定义的Theme。 本文的重点放在BlogEngine.Net的开发规范和实现原理上。如果您对BlogEngine.Net的架构很了解的话，那么开发一个自己的 Theme是一件很简单的事情，如果您不是很了解，那么你也可以按照本文讲述的规范开发出一个自定义的Theme来。

     BlogEngine.Net中的Theme

     在BlogEngine.Net的源代码中默认存储了三个Theme(Standard默认，Mobile移动版，Indigo)，更多的Theme您可以到它的官方站点下载。 同样这些Theme支持热插拔，我们只要把下载的Theme放在themes目录下就可以实现它的安装。相信这种Theme会给用户带来更多的使用上的感 受。由于BlogEngine.Net开放源代码，所以对于Theme的开发也完全由用户自己控制。如果大家想知道这个Theme到底有多厉害，看看 BlogEngine.Net的官方站点就知道了，估计那就是使用BlogEngine.Net，然后换了一个Theme做的。

     规范与原理

     对于用户来说到底使用哪个Theme是存储在BlogSetting中的，在设置页 面中我们可以看到一个下拉列表来选择主题，这个下拉列表的数据是通过读取themes目录下的子文件夹名称获得的，这就要求我们在开发Theme时要以 Theme的名称作为这个文件夹的名称。需要注意的一个问题就是在BlogEngine.Net的Web站点的根目录下的所有.aspx的 Codebehind都是继承自BlogBasePage，这个类又继承自Page类，也就是说BlogBasePage将一些页面中共有的操作进行了统 一的处理，对于这个类我会在接下来的一篇文章中进行分析。

     在BlogBasePage中有这么一段代码:

这段代码就是在页面预初始化时（注意一定要放在这个处理器中）将Page的 MasterPageFiles设置为BlogSetting中所设置主题名称的目录中的site.master，这就要求我们在开发自己的Theme时 需要创建页面的主文件site.master。

     此外就是在研究了PostViewBase和CommentViewBase（这两个类也会在下一篇文章中做详细的说明）的实现以后对于Post和Comment的显示也是到BlogSetting中所设置主题名称的目录中去查找PostView.ascx（直接继承自PostViewBase）和CommentView.ascx（直接继承自CommentViewBase），这就需要我们在开发自己的Theme中需要创建文章的显示界面PostView.ascx和评论的显示界面CommentView.ascx。

     以上几个文件是开发BlogEngine.Net的Theme所必须的，实际上也就形成了一个完整的前台页面了。当然你也可以定义自己的布局，css，图片等。这些文件到底应该如何定义，以Standard为例，先让我们看一下它的实现。

     site.master中依次是资源的引入，header部分，顶部的一些链接，主题部分，版权部分，WidgetZone。请注意：

SearchOnSearch是一个控件，主要完成根据搜索引擎的参数在本站中进行再次搜索。<asp:ContentPlaceHolder ID="cphBody" runat="server" />在site.master中必须存在的，因为Page中已经存在对它的引用。

     PostView.ascx中依次是标题，作者，创建时间，主体，标签，分类，一些链接和管理菜单。其中<asp:PlaceHolder ID="BodyContent" runat="server" />同样也是必须存在的，因为在PostViewBase中就是将Post的内容输出到BodyContent控件中(请参照PostViewBase的Page_Load方法)。

     CommentView.ascx中依次是评论的作者，时间，Gravatar图片显示，内容，管理连接等。这里似乎没有什么是必须的。

     只要遵守这些规范我们就可以开发Theme了，除此之外对于Widget的引入我们也不必使用WidgetZone，只要将这些Widget的控件类直接放在site.master中就行了，其实这已经不能算作一个Widget，只能说是一种类似Widget的控件。对于BlogBasePage，PostViewBase，CommentViewBase以及各个页面之间的继承关系，我会在下一篇文章中做详细的介绍，希望大家继续关注。

     总结

     这篇文章涉及到的内容比较少，并且和下一篇文章有很多联系。实际上，Theme的实现应该是基于BlogBasePage，PostViewBase，CommentViewBase等的，它主要应用了ASP.NET的site.master布局页面，通过动态设置实现。这样操作损失了一个IDE的重要特性——智能感知，开发起来可能会有些不便，但是这样的架构还是不错的。

     看来ASP.NET的site.master的确很有用

     上一篇:BlogEngine.Net架构与源代码分析系列part10：开发扩展（中）——Widget小工具

     返回到目录

     从这篇文章开始的连续三篇文章我将向大家展示BlogEngine.Net中的三大开发扩展特性,它们分别是Extension,Widget和Theme。程序员可以在符合一定标准条件下开发自己的扩展，然后将扩展像插件一样（Plug'n play）与BlogEngine.Net进行集成，来达到个性化的应用。本文将详细介绍第一种扩展Extension的开发标准，管理部分介绍等。

     声明一下
     上一篇文章的回复中有人提到希望我写一下自己的看法和BlogEngine.Net的优缺点等，实际上我想把这些内容放在最后的总结篇里，不过 在以后的每一篇文章中我也会或多或少的加入一些。对于这些看法只是我的一己之见，如果您觉得有帮助那更好，如果有不对之处还请指出。

     什么是Extension与为什么使用Extension

     Extension这个词我很喜欢，具有扩展之意。BlogEngine.Net中的Extension是特指使用了ExtensionAttribute特性标明的类。ExtensionAttribute被定义在BlogEngine.Core.Web.Controls中，继承了.Net中Attribute，内部主要有描述，版本，作者等成员。主要用来标识一个Extension类的信息，以便统一管理模型。BlogEngine.Net中的Extension都被放在了Web站点的App_Code\Extensions或子目录中。它在内部实现时大都是通过静态构造器来监听业务类的消息，并对这些消息提供一些处理。

     Extension在BlogEngine.Net中可以做很多事情，例如：纪录业务日志，对文章的词语进行过滤或替换，对业务类活动的统计分析等。总之，写一些Extension会给你的Blog带来很多意想不到的扩展，目前一些开源社区已经有很多对于BlogEngine.Net的Extension的开发，这里有很多下载，感兴趣的朋友可以研究一下。

     认识一下BlogEngine.Net已有的Extension

     在Web站点的App_Code\Extensions中我们会看到有很多Extension。

     Smilies:监听了Comment.Serving，也就是每当有评论被显示(Serving)时，它就会使用Post_CommentServing处理，主要是将评论中一些词语替换成一些图片。

     SendPings:这里不再说了，在本系列的第七篇文章中已经做了详细的说明。它主要是发送pingback和trackback信息等。

     SendCommentMail:就是每当文章有评论产生时根据配置会向文章作者的邮箱发送评论邮件，功能类似博客园中的评论邮件发送，实现类似Smilies的实现。

     ResolveLinks：也就是每当有评论被显示(Serving)时，解决评论中的超链接过长等问题。

     BreakPost:实现得很有意思，主要是处理文章显示的[more]问题，这都可以作为扩展，真是绝了。从这里我们也能看出以前的一个疑问，那就是Serving的作用，它主要是处理显示问题的，给[more]加入超链接。

     BBCode:似乎是一个在评论显示时，进行字符替换以便按照样式显示的Extension。

     CodeFormatter:这是一个第三方开发的对文章中包含的源代码进行格式输出的Extension。对于它的实现比较复杂，但是结构还是比较清晰的，有兴趣的朋友可以研究一下，这里就不再做过多说明。

     实现一个自己的Extension

     对于开发人员来说实现一个Extension是很简单的事，例如我们想把文章访问的IP纪录下来就可以这样实现：

LoggingIP
 1using#region using
 2
 3using System;
 4using System.Web;
 5using System.Web.UI;
 6using BlogEngine.Core;
 7
 8#endregion
 9
10/**//// <summary>
11/// Logging a browser request IP adrress.
12/// </summary>
13[Extension("Logging a browser request IP adrress.", "1.0", "GUO Xingwang")]
14public class LoggingIP
15{
16
17  /**//// <summary>
18  /// Hooks up an event handler to the Post.Serving event.
19  /// </summary>
20  static LoggingIP()
21  {
22    Post.Serving += new EventHandler<ServingEventArgs>(Post_Serving);
23  }
24
25  /**//// <summary>
26  /// Handles the Post.Serving event to take care of logging IP.
27  /// </summary>
28  private static void Post_Serving(object sender, ServingEventArgs e)
29  {
30    Post post = sender as Post;
31    if (post != null)
32    {
33      // 写入文章标题作为文件名称
34      // 获得IP地址并附加到这个文件
35    }
36  }
37}

     Extension如何被Host起来的

     BlogEngine.Net使用反射技术来启动这些Extension。这些Extension在整个应用程序启动时随之启动，应用程序通过查找已编译的程序集动态加载这些Extension类到内存中来，也就执行了类构造器，实际上这些Extension也就运行起来。我们在Global.asax中可以看到如下代码：

这里请大家注意一下Utils.CodeAssemblies()的实现使用了反射动态加载已编译的程序集（查找程序集的方法）。对于 ExtensionManager.ExtensionEnabled是在管理中判断这个Extension是否启用，ExtensionManager 下文会提到。

     Extension的管理

     这里所说的Extension目前可能还不是很完善。不过它的实现是 BlogEngine.Net非常经典的一部分，很值得去仔细学习和研究,其中很多地方应用到了反射，XML序列化等。它提供给管理员对这些 Extension一个统一的管理，包括控制源代码的浏览，应用和取消Extension，对其进行设置（DataStore）等。由于这部分的源代码比 较多，不适合对其进行更细致的分析，我在这里只是简单介绍一下它的整体设计。

ExtensionManager分成了两部分:
1.逻辑处理，位于App_Code/ExtensionManager中，有四个.cs文件：
ExtensionManager：完成了Extension管理部分常用的方法，也对页面提供一些直接性的服务。
ManagedExtension：是每个可被管理的Extension类的封装。
ExtensionSettings：也是为了管理Extension而封装的设置类，注意它与BlogEngine.Core.DataStore中的同名类的区别。
ExtensionParameter：主要是为ExtensionSettings服务的参数处理的封装。
这些是ExtensionManager主要逻辑，完成包括Extenison配置的加载和存储调用，缓存处理，统一化的管理模型，为页面提供一些直接的服务等。
1.页面管理，位于admin/Extension Manager中，这一部分是调用第一部分来实现管理的，第一部分中有很多信息也是为它服务的：

Default.aspx：一个承载页面，路由导航。
Extensions.ascx：一个Extenison的管理列表。
Editor.ascx：是Extension源代码浏览器。
Settings.ascx：是Extension设置器。注意它实际上是一个统一的配置界面。

对于ExtensionManager的实现逻辑是很复杂的，希望这个整体的介绍能给您阅读代码时带来帮助，如果有不清楚的问题可以给我回复一起讨 论。这一部分我们需要注意一下配置从DataStore的加载和修改是如何完成的，对于逻辑中的配置和参数部分是如何统一化的。

     总结

     我觉得Extension这种扩展非常的优秀，当然这种扩展要想发挥出来肯定对于业务核心部 分地设计是有很多要求的。尤其是它的ExtensionManager对模型的统一性的处理更值得我们去学习和研究，里面的反射机制用的很棒。不过目前这 个ExtensionManager还有很多不太完善的地方，例如源代码修改支持，新Extension的动态添加等，可能BlogEngine.Net 会在将来的版本中提供这些功能吧。

     上一篇:BlogEngine.Net架构与源代码分析系列part8：扩展——DataStore分析

     返回到目录

     本系列的第四篇文章我 给大家做了关于BlogEngine.Net全局配置的分析。在这篇文章里我将会对BlogEngine.Net中比较经典的部分DataStore做一 个简单的分析，这个DataStore主要完成了BlogEngine.Net三大扩展特性(Extension,Widget,Theme)的数据存储 部分，它提供了一个扩展特性统一的存储模型。DataStore是建立在Provider存储（本系列第三篇文章中介绍过）的上层，本文研究的内容会和后面讲到的扩展部分的文章有一定联系，希望大家继续关注。

     BlogEngine.Net三大扩展特性大多数都是由开发者完成的， 也就是说大多数都是后加入到BlogEngine.Net中的，所以这些存储必须单独完成，而且对于模型的统一性很重要。既然是由开发者开发，那么这些标 准就显得格外重要，这样开发出的部分才可以与系统中的部分很好的集成。这里所说的DataStore就是指 BlogEngine.Core.DataStore空间下的类型。

BlogEngine.Net中的DataStore如何设计的

先看一幅继承图吧：

从上图我们可以看到ExtensionSettings和WidgetSettings是SettingBase的直接子类。ExtensionSettings主要是为Extension而对SettingBase的实现，WidgetSettings是为Widget而对SettingBase的实现，对于Theme整个BlogEngine.Net中目前没有涉及到。

ExtensionSettingsBehavior，StringDictionaryBehavior，XMLDocumentBehavior 这三个类都实现了ISettingsBehavior接口，而ISettingsBehavior只有加载配置和保存配置两个方法声明。此外 ExtensionType是一个枚举用来表示扩展的类型。

SettingBase也有加载和保存配置的两个方法，此外SettingBase中还有一个对于ISettingsBehavior的引用，而SettingBase的加载和保存内部也是通过ISettingsBehavior的保存和加载完成的，这好像是一个桥模式。由以上分析我们可以知道对于Extension的数据加载和保存是通过ExtensionSettings完成的，具体实现是由ExtensionSettingsBehavior来做，ExtensionSettingsBehavior的内部使用BlogService调用Provider完成。对于Widget的数据的加载和保存是通过WidgetSettings完成的，具体实现由StringDictionaryBehavior来做，StringDictionaryBehavior的内部也是使用BlogService调用Provider完成，注意SerializableStringDictionary继承自StringDictionary并实现了IXmlSerializable来完成字典对象的序列化和反序列化。

     对于Extension的存储的具体信息通过代码我们可以看到是一个Object，这个Object的格式是由ExtensionManager（这个在后续的相关文章也会讲到）来确定的，也主要是为ExtensionManager服务的。

WidgetSettings的存储的具体信息实际上是一个字典，字典项代表具体信息。

XMLDocumentBehavior主要是为了配置WidgetZone而设计的，它实际上是一个Widget的集合的配置，在页面加载时会读取这些配置来决定怎样显示相应的Widget。

除此之外还需要我们注意的一个地方就是配置对象在XML和数据库的存储表示，实际上它们内部的信息都是一段XML，相应的对于这两种的数据访问的结 果处理也是不一致的（我觉得这个地方设计的不是很好，因为这一层似乎对于Provider有些依赖关系代码，参见 XMLDocumentBehavior.cs，不过还好毕竟是实现依赖于实现嘛，可能也没想出更好的办法）。

客户端的使用

     Extension(App_Code\ExtensionManager\Manager.cs)：

Code
 1/**//// <summary>
 2/// Method to change extension status
 3/// </summary>
 4/// <param name="extension">Extensio Name</param>
 5/// <param name="enabled">If true, enables extension</param>
 6public static void ChangeStatus(string extension, bool enabled)
 7{
 8    foreach (ManagedExtension x in _extensions)
 9    {
10      if (x.Name == extension)
11      {
12        x.Enabled = enabled;
13        BlogEngine.Core.DataStore.ExtensionSettings xs = new BlogEngine.Core.DataStore.ExtensionSettings(x.Name);
14        xs.SaveSettings(x);
15        SaveToCache();
16
17        string ConfigPath = HttpContext.Current.Request.PhysicalApplicationPath + "web.config";
18        System.IO.File.SetLastWriteTimeUtc(ConfigPath, DateTime.UtcNow);
19        break;
20      }
21    }
22}

     StringDictionary(widgets\TextBox\edit.ascx.cs):

Code
1/**//// <summary>
2/// Saves this the basic widget settings such as the Title.
3/// </summary>
4public override void Save()
5{
6    StringDictionary settings = GetSettings();
7    settings["content"] = txtText.Text;
8    SaveSettings(settings);
9}

     XMLDocument(App_Code\Controls\WidgetZone.cs)：

Code
1private static XmlDocument RetrieveXml()
2{
3    WidgetSettings ws = new WidgetSettings("be_WIDGET_ZONE");
4    ws.SettingsBehavior = new XMLDocumentBehavior();
5    XmlDocument doc = (XmlDocument)ws.GetSettings();
6    return doc;
7}

     对于客户端的使用部分涉及到了Extension，Widget部分等，这些内容会在后续的文章中进行详细说明。

总结

1.桥模式的使用

2.统一的配置模型

3.对于XML存储和数据库存储的处理方式不同

     面向对象的设计原则真是太经典了

     上一篇:BlogEngine.Net架构与源代码分析系列part7：Web2.0特性——Pingback&Trackback

     返回到目录

     今 天这篇文章主要向大家讲述一下Blog系统中应用最多的，具有Web2.0特性的，也是一种标准化的——Pingback&Trackback。 分析一下BlogEngine.Net提供的比较全面的Pingback&Trackback支持。本文内容相对来说比较独立，如果您对整个系列 感兴趣请参照这里。

Pingback&Trackback参考

     简单地说，Pingback&Trackback是博客在链接、引用其他博客内容时通知对方博客的一种自动机制，告知对方链接位置及可能包含一定的摘要文本(视情况而定)。这样带来的好处是显而易见的，对Pingback&Trackback发送者来说，避免了手动通知对方的麻烦；对Pingback&Trackback接收者而言，则可以随时掌握自己的某篇文章被什么人链接及具体链接信息，等等。例如:

博客A发布了一篇文章；博客B看到后，发布评论、引用、介绍博客A上该篇文章的贴子；但此时博 客A是无从知道博客B上对自己文章的引用情况的，要让博客A知道，博客B须：在博客A上留言，介绍自己对该篇文章的看法，比如说“在我的博客发布了一篇文 章，也讨论这个问题——”，并附上相应页面的链接；向博客A发送E-mail，说明自己对该篇文章的进一步讨论，同时，也许希望博客A能在页面上放上自己 的链接，以帮助对这一话题有兴趣的用户能找到自己的博客；Pingback&Trackback实现的功能便是将第三个步骤自动化了，再也不需这么一个繁琐的过程，即：博客A发布了一篇文章；博客B看到后，发布评论、引用、介绍博客A上该篇文章的贴子；在文章发布时，博客B即自动向博客A发送Pingback&Trackback；博客A收到相应的Pingback&Trackback，如果未设置人工审核，相应的内容即会出现在博客A该文的留言中，如果设置了人工审核，则出现在博客A的审核列表中，博客A认为不是spam后将其发布在留言中。

BlogEngine.Net中的Pingback&Trackback实现

BlogEngine.Net中的Pingback&Trackback的实现主要涉及到以下几组文件：

1.Web站点App_Code/Extensions中：SendPings.cs
2.BlogEngine.Core的Ping中：PingService.cs、Manager.cs、Pingback.cs、Trackback.cs
3.BlogEngine.Core的Web/HttpHandlers中：PingbackHandler.cs、TrackbackHandler.cs

     从BlogEngine.Net中的Pingback&Trackback的具体实现来看，Pingback和Trackback的区别只在于数据的交换格式上，Pingback和PingService主要是使用标准的XMLRPC来完成数据的交换（上一篇文章中有部分涉及），而Trackback主要的request是使用类似的下面的格式完成：title={0}&url={1}&excerpt={2}&blog_name={3}，response同样是使用XML传输

但是它们要实现的功能是类似的。

     实际上SendPings类是BlogEngine.Net的一个Extension（类具有Extension特性，这个后面会有专门的一篇文章来讲解），它监听了Page.Saved和Post.Saved:

这里再次证明了BusinessBase这种状态维护方式的优越性。

     通过代码我们可以看出当Page或Post被保存时会向 SendPings发出通知，之后SendPings会从线程池中获得一个线程来向PingService发送Ping消息并使用Manager发送 Pingback&Trackback消息。PingService这里主要是处理我们自己设置的Ping服务，对服务地址列表中的服务发送通知 来说明某篇文章已经更新了。Manager主要分析文章中的超链接部分，找到Trackback入口地址，然后向该地址发送Trackback的 TrackbackMessage(这是一个消息的封装，注意它使用Trackback请求的格式重写了ToString方法)，如果发送不成功再向这个 地址发送Pingback消息。Pingback和Trackback这两个类主要完成了Pingback&Trackback消息格式的具体处 理并执行发送之。

Code
 1/**//// <summary>
 2/// Sends the pings in a new thread.
 3/// <remarks>
 4/// It opens a new thread and executes the pings from there,
 5/// because it takes some time to complete.
 6/// </remarks>
 7/// </summary>
 8private static void Post_Saved(object sender, SavedEventArgs e)
 9{
10    if (e.Action == SaveAction.None || e.Action == SaveAction.Delete)
11        return;
12
13    IPublishable item = (IPublishable)sender;
14
15    if ((HttpContext.Current == null || !HttpContext.Current.Request.IsLocal) && item.IsVisible)
16    {
17        Uri url = item.AbsoluteLink;
18        ThreadPool.QueueUserWorkItem(delegate { Ping(item, url); });
19    }
20}
21
22/**//// <summary>
23/// Executes the pings from the new thread.
24/// </summary>
25private static void Ping(IPublishable item, Uri itemUrl)
26{
27    try
28    {
29        System.Threading.Thread.Sleep(2000);
30
31        // Ping the specified ping services.
32        BlogEngine.Core.Ping.PingService.Send(itemUrl);
33
34        // Send trackbacks and pingbacks.
35        if (!BlogSettings.Instance.EnableTrackBackSend && !BlogSettings.Instance.EnablePingBackSend)
36            return;
37
38        if (item.Content.ToUpperInvariant().Contains("\"HTTP"))
39            BlogEngine.Core.Ping.Manager.Send(item, itemUrl);
40    }
41    catch (Exception)
42    {
43      // We need to catch this exception so the application doesn't get killed.
44    }
45}

使用PingbackHandler和TrackbackHandler对外提供支持

     同样PingbackHandler和TrackbackHandler两个 HttpHandler主要是为了使BlogEngine.Net也具有接收Pingback&Trackback消息并处理的能力。它们都是从 请求中获得数据，并将这些数据生成一个Comment对象并关联到相应的文章中，同样它们也提供了 Received，Accepted，Rejected，Spammed四个静态（类）事件来对这一处理周期进行跟踪，外部可以对这些事件提供相应的处理 程序来达到扩展的目的。请大家注意，在Web站点中的Post.aspx中有下面一段代码:

这段代码被使用Html注释掉了，生成的Html为如下格式：

http://localhost/BlogEngine.Web/trackback.axd?id=c3b491e5-59ac-4f6a-81e5-27e971b903ed实际上就是这篇文章的Trackback地址。

     当然这个Trackback地址一般可以由用户自己指定，例如在博客园发文章时我们就可以自己输入一个。

参考文章

1.Trackback和Pingback的区别

2.Trackback, Pingback , Backlink与博客

     有些东西只有成为标准以后才会发光。

     上一篇:BlogEngine.Net架构与源代码分析系列part6：开放API——MetaWeblog与BlogImporter

     下一篇:BlogEngine.Net架构与源代码分析系列part8：扩展——DataStore分析

     返回到目录