这段时间在工作的时候也碰到这情况，于是封装成一个组件方便大家使用。

其实这次发布的组件并不只这些功能，是一个自己用的一个winform简单功能库，不过现有功能还是比较少。

组件采用Apache License 2.0协议。

下载组件

NiuDown视频下载器 1.0

使用方法很简单。

2007-7-16 更新
  * 添加列表任务删除功能
  * 添加任务下载完成后关机
  * 修正标题含有特别字符无法下载

2007-7-22 更新
   * 添加５６视频下载的支持
   * 修正列表任务删除的溢出

NiuDown视频下载器 V1.0 下载

     扯了一些题外话，下面开始进入今天的内容，KDB数据库相对于其它关系型数据库最大的优点就是效率高，特别是对于那些基于列的数据的运算表现更加出色，但它也并不是十全十美的，例如它是一个基于内存的数据库，这也就是说它的效率很大的一个原因就是依赖于数据在内存中的高速传输，这可比硬盘要快得多了。今天我就对它的内存占用率做了一个测试，使用的是开发版本，也就是32位版本，而且运行时间只能是2小时，所以这也是这个测试最多能完成的时间，当前使用的测试是每插入1000行做一次内存使用情况跟所消耗时间的记录，最终结果如下： 

     图中的蓝线代表的是数据库所占用的内存，红线代表的是数据库真正使用的内存，绿线表示每插入1000条数据所需要的时间。

     测试所使用的数据如下：

      从测试结果中我们可以看到数据库启动后会事先向操作系统申请60多M的内存，虽然这么多很多都是被闲置着的，但这么做的好处是当往里面添加数据的时候程序不需要再向操作系统申请内存，这节约了时间。测试发现只要数据量在50万行左右内存基本不会有增加，但如果还有新的数据添加进来，数据库又会一次性申请大量的内存，再接下去还是这样的操作，当数据达到350万行的时候，内存占用情况是400M左右。我想这还是一个可以接受的范围。再看下面的绿线，随着表中数据的不断增加，添加一行记录所需要的时间也在平滑地增长，这可不是什么好消息，不知道关系型数据库是不是也是这样的情况，这个还没有测试过。

     测试所使用的程序：

      1、KDB+数据库，测试所使用的是最新版本2.4；

      2、KdbTester 开发语言为C#，用于产生测试数据；

      3、KdbTestReporter 开发语言为JAVA，使用JFreeChart开源组件来生成报表。

另外 

测试机器的配置如下：
====================================
CPU:    Intel Core 2 Duo E4300
主板:   升技 AB9
内存: 金士顿 DDR2 667 1G x2
显卡:   影驰 GeForce 8600GT 魔灵
硬盘:   酷鱼7200.10 SATAII 8M 250G
电源: Tt 金刚450(W3009)
机箱:   航嘉 H001

操作系统是Vista sp1

为了不让等待的时间太过于无聊，所以自始自终机器都是边跑测试边放电影。

本文将介绍如何从Asp.net中获取WebPart个性化数据，如何存储这些数据。

1 在Asp.Net2.0中，是如何存取WebPart数据的？

在Asp.Net2.0中，默认是通过SqlPersonalizationProvider类存取数据的，提到SqlPersonalizationProvider，就不得不提他的父类PersonalizationProvider，PersonalizationProvider提供了个性化数据的一些抽象方法，来存储和读取WebPart的个性化数据，我们当然也可以建造一个 MyPersonalizationProvider来存取我们自己的个性化数据.

在此着重介绍

• SavePersonalizationBlob()

//
        // 摘要:
        //     将原始个性化设置数据保存到基础 Microsoft SQL Server 数据库中。
        //
        // 参数:
        //   webPartManager:
        //     管理个性化设置数据的 System.Web.UI.WebControls.WebParts.WebPartManager。
        //
        //   userName:
        //     System.Web.UI.WebControls.WebParts.PersonalizationScope.User 范围中要用作关键字的个性化设置信息的用户名。
        //
        //   dataBlob:
        //     要保存的数据的字节数组。
        //
        //   path:
        //     指示要保存的个性化设置信息的 System.Web.UI.WebControls.WebParts.PersonalizationScope。此值不能为null。

protected abstract void SavePersonalizationBlob(WebPartManager webPartManager, string path, string userName, byte[] dataBlob);

参数webPartManager就是你的页面上的放的webPartManager

参数path指的是你的WebPart部署在哪个页面上，在Index.aspx上还是Default.aspx上

参数userName，如果你使用了MemberShip,则返回你的UserName.

参数dataBlob，就是WebPart个性化数据，你可以存储在任意的Image字段中

如果您有一个这样的数据结构：

您就可以将WebPart数据掌握在自己手中了。

我们可以参考一下SqlPersonalizationProvider中是如何存储的

SavePersonalizationBlob
private void SavePersonalizationState(SqlConnection connection, string path, string userName, byte[] state)
{
    SqlCommand command;
    if (userName != null)
    {
        command = new SqlCommand("dbo.aspnet_PersonalizationPerUser_SetPageSettings", connection);
    }
    else
    {
        command = new SqlCommand("dbo.aspnet_PersonalizationAllUsers_SetPageSettings", connection);
    }
    this.SetCommandTypeAndTimeout(command);
    command.Parameters.Add(this.CreateParameter("@ApplicationName", SqlDbType.NVarChar, this.ApplicationName));
    command.Parameters.Add(this.CreateParameter("@Path", SqlDbType.NVarChar, path));
    command.Parameters.Add(this.CreateParameter("@PageSettings", SqlDbType.Image, state));
    command.Parameters.Add(this.CreateParameter("@CurrentTimeUtc", SqlDbType.DateTime, DateTime.UtcNow));
    if (userName != null)
    {
        command.Parameters.Add(this.CreateParameter("@UserName", SqlDbType.NVarChar, userName));
    }
    command.ExecuteNonQuery();
}

• LoadPersonalizationBlobs()

//
       // 摘要:
       //     根据指定参数从基础数据存储区加载个性化设置数据。
       //
       // 参数:
       //   sharedDataBlob:
       //     为 System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared 范围返回的数据。
       //
       //   webPartManager:
       //     管理个性化设置数据的 System.Web.UI.WebControls.WebParts.WebPartManager。
       //
       //   userName:
       //     System.Web.UI.WebControls.WebParts.PersonalizationScope.User 范围中要用作检索关键字的个性化设置信息的用户名。
       //
       //   userDataBlob:
       //     为 System.Web.UI.WebControls.WebParts.PersonalizationScope.User 范围返回的数据。
       //
       //   path:
       //     System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared 范围中要用作检索关键字的个性化设置信息的路径。

protected abstract void LoadPersonalizationBlobs(WebPartManager webPartManager, string path, string userName, ref byte[] sharedDataBlob, ref byte[] userDataBlob);

前几个参数就不一一介绍了，它们和SavePersonalizationBlob()中使用的参数并无二致。只是个性化参数分了sharedDataBlob和userDataBlob。

如果某个WebPartManager中设置Personalization-InitialScope指定为User的，则属性的值存储在userDataBlob中；如果指定为Shared，则存储在sharedDataBlob。

或者是设置某个个性化属性

[ResourceWebDisplayName(""), Personalizable(PersonalizationScope.Shared)]
        public long MyProperty
        {
            get {
                return _myProperty; }
            set { _myProperty= value; }
        }

我们也参考一下SqlPersonalizationProvider是如何读取的。
LoadPersonalizationBlobs
protected override void LoadPersonalizationBlobs(WebPartManager webPartManager, string path, string userName, ref byte[] sharedDataBlob, ref byte[] userDataBlob)
{
    sharedDataBlob = null;
    userDataBlob = null;
    SqlConnectionHolder connectionHolder = null;
    SqlConnection connection = null;
    try
    {
        try
        {
            connectionHolder = this.GetConnectionHolder();
            connection = connectionHolder.Connection;
            this.CheckSchemaVersion(connection);
            sharedDataBlob = this.LoadPersonalizationBlob(connection, path, null);
            if (!string.IsNullOrEmpty(userName))
            {
                userDataBlob = this.LoadPersonalizationBlob(connection, path, userName);
            }
        }
        finally
        {
            if (connectionHolder != null)
            {
                connectionHolder.Close();
                connectionHolder = null;
            }
        }
    }
    catch
    {
        throw;
    }
}






2 我们写好了MyPersonalizationProvider，怎么将它应用到我们的系统中呢？

很简单，只要在Web.config中的<System.web>节中指定

<webParts>
            <personalization defaultProvider="MyPersonalizationProvider">
                <providers>
                    <clear/>
                    <add name="MyPersonalizationProvider" type="MyCompany.MyPersonalizationProvider" connectionStringName="Default"/>
                </providers>
            </personalization>
        </webParts>

 至此，您就可以完全抛弃aspnetdb数据库了，再建立任何的webpart应用都不需要跑一次aspnet_regsql.exe来初始化
aspnetdb数据库

这个新的版本里有一堆新特性和功能，实际上其数目之多，我决定我需要2个帖子才能对它们全部论及，这第一个贴子将讨论第四个预览版中的缓存（Caching）,错误处理（Error Handling）和安全（Security）新特性，以及一些测试方面的改进，我下一个贴子将讨论这个版本中新加的AJAX特性。

理解过滤拦截器（Filter Interceptors）

Action过滤器属性（Filter Attributes）是ASP.NET MVC中一个非常有用的扩展功能，这个东西最初是在第二个预览版中加入的，允许你在对MVC控制器的请求中注入拦截代码，在 Controller和它的Action方法执行的前后执行，这可以促成一些非常棒的封装场景，在其中，你能以一种非常干净的，声明的方式轻松地封装和重用功能。

下面是一个极其简单的例子，ScottGuLog过滤器，我可以用它来记录在请求的执行过程中抛出的异常的细节。实现一个定制的过滤器类非常容易，只要继承自ActionFilterAttribute类型，覆盖其中的适当方法，在Controller的Action方法调用之前或之后，或者在ActionResult处理进回复之前或之后运行代码。

在ASP.NET MVC Controller中使用过滤器也是非常容易的，只要在Action方法上将其声明为一个属性，或者在Controller类本身之上声明即可（在这个情形下，它将运用于Controller中所有的Action方法）：

在上面，你可以看到应用了的2个过滤器的例子，我表示要将“ScottGuLog”运用于“About”这个Action方法，而将“HandleError”过滤器运用于HomeController的所有Action方法之上。

ASP.NET MVC的以前几个预览版本早就开启了这个过滤器扩展性，但并没有发布预制的过滤器，这第四个版本包含了几个有用的过滤器，可以用来处理输出缓存，错误处理以及安全的场景。

OutputCache过滤器

[OutputCache]过滤器提供了一个简易的方式，将ASP.NET MVC与ASP.NET的输出缓存功能相结合（在ASP.NET MVC第三个预览版中，你要编写代码才能实现这个功能）。

想试验一下的话，修改HomeController（是由VS ASP.NET MVC项目模板生成的）中的Index Action方法的Message值来显示当前时间：

在运行这个应用时，每次刷新页面，你都会看到时间戳更新：

我们可以在我们的Action方法上加[OutputCache]属性来给这个URL启用输出缓存，我们将使用下面的声明来配置缓存回复10秒钟：

现在，当你点击刷新时，你会看到时间戳每10秒钟才更新一次。这是因为action方法每10秒钟才会被调用一次，其他时间的所有请求都是从ASP.NET输出缓存中供应的（意味着不用运行什么代码，所以请求的回复超快）。

除了支持时间间隔外，OutputCache属性还支持标准的 ASP.NET 输出缓存变化选项（随参数，头内容，内容编码以及定制逻辑而变化）。例如，下面的例子会根据PageIndex查询字符串参数的值保存不同的页面缓存版本，然后会根据进来的URL的查询字符串值自动显示正确的版本：

你还可以结合ASP.NET的数据库缓存失效功能，该功能允许你在URL依赖的数据库被修改后自动导致缓存失效（小技巧：实现这个功能的最佳方案是在你的web.config中配置一个CacheProfile节，然后在OutputCache属性中配置指向该节点）。

HandleError过滤器

[HandleError]过滤器提供了一种声明的方式，来在一个Controller或一个Action方法上表示，如果在处理一个ASP.NET MVC请求中发生错误的话，应该显示一个友好的错误回复。

要试验一下的话，在项目中加一个新的TestController，实现一个action方法，在其中象下面这样抛出一个异常：

在默认情形下，如果将浏览器指向这个URL的话，它会给远程用户显示一个默认的ASP.NET错误网页（除非你去web.config文件中配置了<customErrors>节）：

我们可以在我们的Controller类或其中的Action方法上加一个[HandleError]属性，来改变要显示的HTML错误，而显示对终端用户比较友好的信息：

HandleError过滤器会捕捉住所有的异常（包括处理视图模板时抛出的错误），在出错时显示一个定制的Error视图回复。在默认情形下，它试图在你的项目中寻找一个名为“Error”的视图模板来生成回复。你可以将“Error”视图置于同个Controller相应的视图的目录之中（例如，上面的TestController的\Views\Test目录），也可以置于\Views\Shared文件夹中（系统会先找一个特定于控制器的出错视图，如果没找到的话，会在Shared文件夹中寻找，该文件夹包含了为所有控制器所共享的视图）。

从第四个预览版开始，在你创建新的ASP.NET MVC项目时，Visual Studio现在会自动为你在\Views\Shared文件夹中加一个默认的“Error”视图模板：

在我们的TestController类上加[HandleError]属性后，在默认情形下，它会给远程用户显示一个象下面这样的HTML错误页面（注意，它使用了项目的母板页，这样就将错误信息集成进了站点之中）。很明显地，你可以去定制这个Error视图模板，显示你想要的任何HTML或者更加友好的错误信息，下面只不过是随该版本而来的原装的信息：

为帮助开发人员，在本地浏览应用时，Visual Studio中由新的项目模板提供的默认的Error视图模板还会显示额外的错误堆栈跟踪信息：

你可以在Error视图模板中将代码删除来将其关闭，或者也可以在你的web.config文件中将<customErrors>设成“Off”。

在默认情形下，[HandleError]过滤器将捕捉和处理请求中抛出的所有异常。你也可以在[HandleError]属性上指定 "ExceptionType"和"View"属性来指定你感兴趣的特定异常类型，以及指定定制的错误视图：

在上面的代码中，我选择为SqlException和NullReferenceException异常显示定制的错误视图，所有其它的异常则将使用默认的“Error”视图模板。

Authorize过滤器

[Authorize]过滤器提供了一种声明的方式来控制对Controller或Action方法的访问权限，它允许你表示用户必须已经登录，或者要求他们必须是某个特定的用户或是某个特定的安全角色才能访问。这个过滤器可以用于任何类型的认证方式（包括基于Windows以及Forms的认证），还提供了自动将匿名用户转向到登录页面的支持。

要试验一下的话，在Visual Studio中给默认生成的HomeController中的“About” action方法加一个[Authorize]过滤器：

象上面这样声明[Authorize]属性表示用户必须已经登录进网站才能请求“About” action。如果还没登录的用户试图访问/Home/About URL的话，他们会无法访问该页。如果web应用是配置成使用基于Windows的认证的话，ASP.NET会自动使用他们的Windows登录身份来认证用户，如果成功的话，就会允许他们访问。如果web应用是配置成使用基于Forms的认证的话，[Authorize]会自动地将用户转向到登录页面以作认证（之后他们就能访问了）：

[Authorize]属性也允许你将访问权限只授予特定的用户或角色。例如，如果我要将"About" action的访问权限只限于我自己和Bill Gates的话，我可以这么写：

一般来说，除了无关紧要的应用外，你不该在代码中硬写用户名字，一般地，你应该使用象“角色”这样的比较高层次的概念来定义权限，然后另外将用户映射到角色上（例如，使用活动目录或数据库来储存这些映射）。[Authorize]属性通过使用“Roles”属性，极大地方便了对Controllers和Actions的访问的控制：

[Authorize]属性并不依赖于任何特定的用户身份或角色管理机制，它只用ASP.NET的"User"对象，该对象是可扩展的，允许使用任何身份系统。

AccountController类

我在上面提到了[Authorize]属性可用于任何认证或用户身份管理系统，你可以编写或使用你想要的任何定制的登录UI或用户/密码管理系统。

但为助你起步，Visual Studio中的ASP.NET MVC项目模板现在包含了一个预制的“AccountController”类以及相关的登录视图，它们实现了表单认证成员系统，支持登录，退出，注册新用户，改变密码等。所有的视图模板和UI都可以轻松地定制，是独立于 AccountController 类或实现的：

Site.master模板在右上角也包括了UI，提供登录/退出功能，在使用基于表单的认证时，如果你目前还没认证的话，它会提示你登录：

在你通过认证后，它会显示一个欢迎信息，以及一个退出链接：

点击上面的Login链接，会将用户转到象下面这样的登录屏幕来做认证：

新用户可以点击注册链接来创建新的帐号：

错误处理和错误信息显示也是内置的：

加到新项目中的AccountController类使用了内置的ASP.NET Membership API来存储和管理用户凭证（Membership系统使用了提供器API，允许接入任何后台存储，ASP.NET包含了内置的Active Directory 和 SQL Server提供器）。如果你不想使用内置的Membership系统的话，你可以保留同样的AccountController action方法签名，视图模板，Forms认证ticket逻辑，只要替换掉AccountController类中的用户帐号逻辑就可以了。在下一个ASP.NET MVC预览版中，我们计划将AccountController和用户身份系统间的交互逻辑封装成一个接口，这将进一步方便你接入你自己的用户存储系统（而不必实现一个完整的membership提供器），以及方便你对它和AccountController进行单元测试。

我们的希望是，这给大家提供了一个很好的快速起步的方式，允许大家在创建一个新项目后，就有一个工作的end to end的安全系统。

测试TempData

在这第四个预览版的第一个贴子里要提到的最后一个改进是对Controller类所做的一些改进，这些改进将允许你更轻松地单元测试TempData集合，TempData 属性允许你保存你要持久到将来一个用户请求的数据，它的意义在于，只持续到下一个请求为止（之后就被去除了）。一般用于这样的MVC场景： 你想要进行一个客户端的重新定向来改变浏览器中的URL，然后想要一种简便的方式来保存临时的数据。

在以前的ASP.NET MVC预览版中，你需要mock对象才能测试TempData集合。在第四个预览版中，你不再需要mock或设置什么了，你现在可以在单元测试中，直接在Controller的TempData集合中添加和核实对象（例如，在调用控制器的一个action方法之前填充它的TempData属性，或者在action方法返回后核实action方法更新了TempData）。TempData集合的实际存储机制现在封装在单独的TempDataProvider属性中了。

结论

希望上面的贴子内容对即将发布的ASP.NET MVC的第四个预览版中的若干新特性和变动提供了一个简单的介绍，下一个贴子将讨论新加的 AJAX 功能，并且示范如何利用它。

希望本文对你有所帮助，

Scott

使用方法很简单。

下载