博客园_〖老四〗的技术空间-All For Better Codes

关于MVC权限控制的一点小想法

2010-12-15T02:32:00Z

近来一直在学习MVC。

先检讨一下自己，本来一直在看WPF并向Silverlight靠拢的，可XAML这个东西一时半会领会不了它的真谛，所以暂时先放下了。虽然MVC看的比较系统，但暂时闲置了WPF和Silverlight还是有点沮丧感，觉得自己没有坚持。

MVC的权限控制一直是一个麻烦事。

Webform下的窗体身份验证及角色权限管理，我自己有一篇文章做了个总结：Asp.Net实现FORM认证的一些使用技巧。

对于MVC，我不喜欢它自带的Membership那一套，也不喜欢用Linq，所以我着重参考了这篇文章：ASP.NET MVC：窗体身份验证及角色权限管理示例。文章的内容很好，将FORM认证和MVC很好的结合起来，而且角色权限可控制到Action的级别。

今天我在做自己写的一个简单示例程序时发现，如果当我们的权限管理比较粗狂时，比如，我只需要根据是否登录来判断页面是否需要访问时，如果还是为每一个Controller下的每一个Action都增加属性[Authorize]，那就太麻烦了。我在想能不能控制到Controller级别呢？于是做了下面的尝试：

1 [Authorize]
2 public class AccountController : BaseController
3 {
4 }

即将属性[Authorize]写到Controller级别，发现是可用。这样就控制了整个Controller都需要认证后才能访问。但是还是得为每一个Controller下都增加属性[Authorize]，也有点麻烦。于是，我想到了Webform下常会做一个Pagebase类，我又做了下面的尝试：

1 [Authorize]
2 public class BaseController : Controller
3 {
4 }
5
6 public class AccountController : BaseController
7 {
8 }

也就是建立一个BaseController基类，带上[Authorize]属性，然后需要认证的Controller都继承这个基类即可。测试通过，那就OK了。今天工作差不多就能到这了。

但也有一些问题，比较普遍的就是在控制Action的角色权限时，需要写死[Authorize(Roles = "manager")]。很多人在问，能不能那个角色能动态的从数据库读取呢？其实我也没有办法。包括以前Webform认证时按角色控制目录的访问属性，也需要在Web.config中写死。

不过，我有个想法，还没实践，那就是在BaseController中增加相应的虚Action或抽象Action，在这一级定义好[Authorize]属性，或者进行动态的读取，其余的Action重写实现就可以了。不知道可不可行。有时间试一下。

今天暂时就这么多，记一下，给自己也是个提醒。

本文链接

jQuery UI 应用不同Theme的办法

2010-09-11T11:06:00Z

jQuery UI是一套非常好用的jQuery Tools库，目前已经发布的最新版本是1.8.4。在我自己的使用过程中，总有一些不爽。因为我下载的那个包里默认的主题样式是下图这样的，使用起来很难和具体的网页风格去配合。

一开始，我准备去动手，自己修改CSS文件。这被证明是个非常费力不讨好的事情。

有一次在jQuery UI的主页【http://jqueryui.com/home】停留的时候，一个单词很快吸引了我的注意：【themeable】，这不就是“可变主题的”的意思吗？于是我进入到【http://jqueryui.com/themeroller/】这里，发现了下图的这个地方，他们官网的人把主题的更换叫做“主题滚轮”（哈哈哈，翻译水平一般，信达雅也不知道满足了多少）。

第一个TAB页里说的是【滚出我们自己的主题样式】。打开下面各个分项后，可以自己定义自己需要的样式，定义好以后，点那个下载的按钮就可以下载自己定义好的一套主题样式了。这比自己动手去改CSS文件什么的方便多了。

第二个TAB页打开后，就发现原来他们已经准备好了很多的主题。这对于我这样的懒人很合适，这么多的样式总有一个是我想要的。

选中自己喜欢的样式，点击下载按钮，会自动转到下载页面，然后就能把自己想要的主题样式包给下载下来了。也可以在下载页面的【Theme】区的下拉框里选择自己需要的主题，我选择的是【Cupertino】。

两个压缩包下载下来（注意：不同的主题样式，压缩包名称是一样的，保存时别覆盖了），解压以后就发现，不同的主题其实只有CSS文件夹中的内容不同，也就是主题包的资源不同（主题包资源包括图片和CSS文件）。其它的都是一样的，文件夹文件名都一样，甚至于文件里面的元素的命名都是一样的。

在应用的项目工程中，只需要将主题包和【jquery-ui-1.8.4.custom.min.js】文件加入工程，就可以使用可变主题的jQuery UI了。如图：

我们所要做的就是在需要使用jQuery UI的页面中添加对于CSS文件和JS文件的引用即可。我一般是在母版页里添加。

当我们要更换jQuery UI的主题样式时，只需要修改对CSS的引用路径即可实现。如下图，这个颜色的部分就是修改的地方。

这里【http://jqueryui.com/demos/tabs/】是jQuery UI的一些使用示例的介绍，这个地址已经直接进入到TAB控件的使用说明。使用说明的页面布局如下图：

左边：选择你要显示的对象；

中间：是运行时的实际效果显示的地方，点击【View Source】能显示源代码；

右边：是选中对象的一些扩展功能的示例，选择不同的功能，显示区即会有随之变化，源代码区也会跟着变更；例如：上图选择【Open on mouseover】，Tab控件的Tab Page则由原来需要点击才能切换变成了只需要鼠标移动上去就可以切换了。

最后，再次强烈推荐jQuery UI。

本文链接

Asp.Net实现FORM认证的一些使用技巧

2010-07-09T05:07:00Z

最近因为项目代码重构需要重新整理用户登录和权限控制的部分，现有的代码大体是参照了.NET的FORM认证，并结合了PORTAL KITS的登录控制，代码比较啰嗦，可维护性比较差。于是有了以下的几个需求（大多数系统应该都会碰到）：

用.NET自带的FORM认证来实现安全登录
登录后需要记录登录用户的基本信息，方便所有页面调用
记录本机登录状态，短时间关闭窗口后不用重新登录
权限控制和代码的文件夹结构相呼应，即按角色允许访问不同的目录
权限控制有可能需要细化到每一个页面，即按角色允许访问不同的页面
以上的部分尽量自己少写代码，用自带的类库和机制实现

第一步：准备工作

先准备一个名为Test的WEB项目，包含：

Default.aspx，默认页，随便显示一些信息，

Web.config，配置页面。

注册页与登录页在同一目录的机妙后面会说。

第二步：Web.config文件的修改

1、打开Web.config文件，找到authentication节，将其改为如下：

配置节属性的具体意义和其他没有加入的属性网上到处都有查。这里注意一下的是authentication节和authorization节，两个单词很相似，但却不是同一个单词，每个节下面的内容也不能写到一起。

其中，authorization节中的“allow”表示允许的意思，“*”表示所有用户；而“deny”表示拒绝的意思；“?”表示匿名用户；此处加入后，则代表根目录下的所有文件和所有的子目录都不能匿名访问，Login.aspx 页面除外。

2、Web.config中，Location节的应用

做了上面的配置之后，我们会发现，在没登录的情况下，用浏览器打开Default.aspx会自动转到Login.aspx，同理Register.aspx页面也会如此。问题：注册用户怎么可能在登录后才能访问呢？

那么我们就得说了，当注册页与登录页在同一目录，为了达到不用登录就能访问注册页的目的，我们就得对访问限制的Web.config配置处理一下。

方法一：注册页与登录页放在不的目录内

我们在根目录添加一个文件夹Pub，将Register.aspx移动到此文件夹里，此时仍不能访问，需要在文件夹内添加一个Web.config文件，加入：

此处，即说明此目录下的所有文件，允许所有人访问。

关于 Web.config 作用范围的说明：

Web.config 的设置将作用于所在目录的所有文件及其子目录下的所有东东（继承：子随父姓）
子目录下的 Web.config 设置将覆盖由父目录继承下来的设置（覆盖：县官不如现管）
也就是，属性设置由最深一层的目录里的Web.config决定；如果子目录里没有Web.config文件，则由离它最近的父目录里的Web.config决定

方法二：仍然保持注册页和登录页在同一目录下

只需要在根目录下的Web.config 中加入以下一段：

通过location节的path属性的值指定Register.aspx页面，以及下面authorization节的设置，说明了Register.aspx页面是允许被所有人访问。

注意：

location节应加在原有的system.web节的外面，包含在configuration节内，和system.web节是同级的。

当根目录下，有多个页面不需要登录就可以访问时，可以设置多个location节，修改对应path属性值指向的页面就可以了。

另外，path属性的值也可以指定目录，用来指定该目录的访问限制。通过修改authorization节的内容来限定访问权限。详细的设置，后面会提到。

第三步：实现登录的代码

1、普通的代码实现

方法一：

如果forms节中设置了“defaultUrl”的属性，也就是登录后默认转向的页面，则可以用如下的方法：

private void Btn_Login_Click(object sender, System.EventArgs e)
{
  if(this.Txt_UserName.Text=="Admin" && this.Txt_Password.Text=="123456")
  {
     FormsAuthentication.RedirectFromLoginPage(this.Txt_UserName.Text,false);
  }
}

此处只是简单模拟了一下登录的验证过程，RedirectFromLoginPage方法能发送验证票据验证Cookie（如何进行可以用Reflector去查看源代码），返回请求页面，即“从哪来就打哪去”。比如：用户没登录前直接在 IE 地址栏输入 http://localhost/Test/Default.aspx ，那么该用户将看到的是 Login.aspx?ReturnUrl=Default.aspx ，输入用户名与密码登录成功后，系统将根据“ReturnUrl”的值，返回相应的页面；如果没有“ReturnUrl”，则按照“defaultUrl”的属性自动转向。

方法二：

private void Btn_Login_Click(object sender, System.EventArgs e)
{
   if(this.Txt_UserName.Text=="Admin" && this.Txt_Password.Text=="123456")
   {
      FormsAuthentication.SetAuthCookie(this.Txt_UserName.Text,false);
      Response.Redirect("Default.aspx");
   }
}

此处是分两步走：通过验证后就直接发放 Cookie ，跳转页面将由程序员自行指定，无需“defaultUrl”设置。此方法对于程序员来说，更灵活。

2、手工实现需要记录用户登录信息的情况

当我们需要记录用户登录的信息，不单单只是一个ID还需要更多属性的时候，一般都用一个类存储到Session或Cookie实现，然后做一个基类页，在基类页中设置属性来读取Session或Cookie。

Session实际也和支不支持Cookie有关，且存在服务器，多少会占用服务器端资源。因此这里还是考虑用Cookie实现。那么在RedirectFromLoginPage方法或SetAuthCookie方法已经设置了验证票据并设置了Cookie，我们能不能把用户登录信息也存储到这个默认的Cookie里呢？答案是能。

首先，我们在项目里添加AppCode目录，增加一个UserInfo的类，用以简单模拟用户登录信息。代码如下：

[Serializable]
public class UserInfo
{
    //用户登录信息
    private int _nId;
    private string _sRealName;
    private string _sName;
    private string _sPassword;
    private string _sRoles;

    public int Id
    {
        get { return this._nId; }
        set { this._nId = value; }
    }
    public string RealName
    {
        get { return this._sRealName; }
        set { this._sRealName = value; }
    }
    public string Name
    {
        get { return this._sName; }
        set { this._sName = value; }
    }
    public string Password
    {
        get { return this._sPassword; }
        set { this._sPassword = value; }
    }
    public string Roles
    {
        get { return this._sRoles; }
        set { this._sRoles = value; }
    }

    public UserInfo()
    {
    }
}

需要注意，类的属性中一定要加[Serializable]，表示类可以序列化。

Forms验证在内部的机制是，把用户数据加密后保存在一个基于cookie的票据FormsAuthenticationTicket中，通过RedirectFromLoginPage方法或SetAuthCookie方法就已经实现了Ticket和Cookie的设置，也就是设置了Context.User的值，Context.User在取值和判断是否经过验证的时候很有用处。Cookie的属性是在Web.config的<forms name=".ASPXAUTH" loginUrl="Login.aspx" protection="All" path="/" timeout="20"/>中设置的。因为是经过特殊加密的，所以应该来说是比较安全的。

而.net除了用这个票据存放自己的信息外，还留了一个地给用户自由支配，这就是现在要说的Ticket的UserData。 UserData用来存储string类型的信息，并且也享受Forms验证提供的加密保护，当我们需要这些信息时，也可以通过简单的Ticket的UserData属性得到，兼顾了安全性和易用性，用来保存一些必须的敏感信息还是很有用的。我们就准备将用户的登录信息记录在UserData中，代码如下：

protected void Button1_Click(object sender, EventArgs e)
    {
        if (this.TextBox1.Text == "Admin" && this.TextBox2.Text == "123456")
        {
            // 加密UserInfo
            UserInfo user = new UserInfo();
            user.Id = 1;
            user.Name = this.TextBox1.Text;
            user.Password = this.TextBox2.Text;
            user.RealName = "系统管理员";
            user.Roles = "Administrators,Users";
            string strUser = Serialize.Encrypt<UserInfo>(user);

            // 设置Ticket信息
            FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(
                1, user.Name, DateTime.Now, DateTime.Now.AddMinutes(20), false, strUser);

            // 加密验证票据
            string strTicket = FormsAuthentication.Encrypt(ticket);

            // 使用新userdata保存cookie
            HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, strTicket);
            cookie.Expires = ticket.Expiration;
            this.Response.Cookies.Add(cookie);


            this.Response.Redirect("Default.aspx");
        }
}

上面的代码，实际上类似于手工实现了SetAuthCookie方法的过程。

首先，模拟实现登录，我们手动设置了一个UserInfo的对象，string strUser = Serialize.Encrypt<UserInfo>(user) 是将对象序列化成字符串的一个方法。

然后，生成一个FormsAuthenticationTicket票据。此处用到的FormsAuthenticationTicket构造函数的重载方法的签名解释

public FormsAuthenticationTicket(
int version, //版本号
string name, //与身份验证票关联的用户名
DateTime issueDate, //票据的发出时间
DateTime expiration,//票据的到期日期
bool isPersistent, //票据是否存储在持久的 Cookie 中，是为 true；否则为 false
string userData //票据中存储的用户定义数据
);

其中，name的设置与Context.User.Identity.Name对应，且大小写敏感，也与将来的权限控制相关，赋值的时候需要特别注意。另外，票据的到期日期和Web.config中设置的Cookie的到期日期不是同一个概念，如果分不清，请到网上去搜索，如果实在不想在这上下功夫，后面会有处理的方法。

再后，string strTicket = FormsAuthentication.Encrypt(ticket) 将票据加密成字符创

最后，HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, strTicket) 生成Cookie。
FormsAuthentication.FormsCookieName获取的就是Web.config中配置的Cookie名称，也就是默认验证时产生的Cookie。cookie.Expires = ticket.Expiration 将票据的过期时间和Cookie的过期时间做了同步，也就避免了两者不同所产生的矛盾。这样，验证票据生成了，存储到默认配置的Cookie中，也就是类似实现了一个SetAuthCookie方法的过程。通过Context.User就能获取票据的相关信息了。

3、获取信息

为了在其他登录后的页面比较简单的获取登录用户信息，我们先生成一个基类页面。在AppCode中新增LoginBasePage类，代码如下：

public class LoginBasePage : Page
{
    protected UserInfo LoginUser
    {
        get
        {
            string strUser = ((FormsIdentity)this.Context.User.Identity).Ticket.UserData;

            return Serialize.Decrypt<UserInfo>(strUser);
        }
    }

    public LoginBasePage()
    {
        //
        // TODO: 在此处添加构造函数逻辑
        //
    }
}

LoginBasePage : Page，基类页要继承Page，成为所有登录以后的页面的基类。

属性protected UserInfo LoginUser{ get；}用来访问登录信息。将Context.User.Identity强制转换为FormsIdentity类的对象，通过访问Ticket属性的UserData属性，获得被序列化后的对象的字符串，最后用方法Serialize.Decrypt<UserInfo>(strUser)将字符串反序列化成对象后再返回UserInfo类型的对象。

我们只需要将Default页面的后台代码改为public partial class _Default : LoginBasePage，就可以通过this.LoginUser来访问用户登录信息了。

第四步：实现不同目录的权限控制

上面，实现了记录用户登录信息的模拟登录过程，以及根目录下文件的访问控制。但是系统一般都会有多个目录，接下来就说说目录的访问控制。

其实，上面多多少少已经提到过了，通过在每个目录下增加Web.config文件来进行访问限制。

首先，我们在根目录增加一个文件夹ManageAdmin，在此文件夹内增加页面UserInfo.aspx，页面内放几个Label用来展现登录用户信息。

然后，再增加一个Web.config文件，配置内容如下：

配置中说明只允许“Admin”用户访问，禁止其他所有用户访问。

这里，特别要注意的是，FormsAuthenticationTicket票据的name属性的赋值，一定要和<allow users="Admin"></allow>设置的用户想对应，且大小写敏感。如果要设置允许多个用户访问，则用“,”隔开，例如<allow users="Admin,User1"></allow>。

不同的目录，设置不同的允许访问的用户，就可以对所有目录进行访问控制了。

第五步：实现不同目录的按角色的权限控制

以上实现了对不同目录按用户的访问限制。但是一般来说，一个网站系统的用户会很多，如果一直使用精确到用户的访问控制，则会造成设置Web.config的工作量加大。

而一般，我们会将用户分到不同的用户组来进行权限控制，因此，我们也可以配置Web.config实现按角色来控制不同的目录的访问权限。

首先，我们在根目录下再增加一个目录ManageUsers，在此文件夹内也增加页面UserInfo.aspx用来展现登录用户信息。此目录将模拟控制Users组的用户，文件夹ManageAdmin将模拟控制Administrators组的用户。

然后，在目录ManageUsers增加Web.config文件，配置内容如下：

再将文件夹ManageAdmin下的Web.config文件的<allow users="Admin"></allow>改成<allow roles="Administrators"></allow>。

最后，修改代码。

1、注意，我们在模拟用户信息的时候，有这么一句，user.Roles = "Administrators,Users";也就是用户Admin具备两种角色

2、为模拟Users组的用户登录，我们再添加如下代码：

if (this.TextBox1.Text == "User1" && this.TextBox2.Text == "111111")
{
            // 加密UserInfo
            UserInfo user = new UserInfo();
            user.Id = 2;
            user.Name = this.TextBox1.Text;
            user.Password = this.TextBox2.Text;
            user.RealName = "普通用户1";
            user.Roles = "Users";
            string strUser = Serialize.Encrypt<UserInfo>(user);

            // 设置Ticket信息
            FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(
                1, user.Name, DateTime.Now, DateTime.Now.AddMinutes(20), false, strUser);

            // 加密验证票据
            string strTicket = FormsAuthentication.Encrypt(ticket);

            // 使用新userdata保存cookie
            HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, strTicket);
            cookie.Expires = ticket.Expiration;
            this.Response.Cookies.Add(cookie);


            this.Response.Redirect("Default.aspx");
  }

这样，我们登录时，输入“Admin”和“User1”的时候，就可以模拟不同角色的用户登录了。

3、Forms基于角色的验证的内部机制是，将角色的属性也设置到了Context.User中，这里也需要手工代码处理一下。　

首先，为了支持基于角色的验证，我们每进入一个页面都需要将角色信息设置到Context.User中，那么最好的办法就是在Global.asax 文件中的Application_AuthenticateRequest方法中设置。

Application_AuthenticateRequest方法，是在每次验证请求时触发，它与另外一个方法Application_BeginRequest的区别就在于，Application_AuthenticateRequest方法内，能够访问Context.User.Identity，而Application_BeginRequest则无法访问。

我们在根目录添加一个Global.asax 文件，增加如下代码：

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
    {
        if (this.Context.User != null)
        {
            if (this.Context.User.Identity.IsAuthenticated)
            {
                if (this.Context.User.Identity is FormsIdentity)
                {
                    string strUser = ((FormsIdentity)this.Context.User.Identity).Ticket.UserData;

                    string[] roles = Serialize.Decrypt<UserInfo>(strUser).Roles.Split(',');

                    this.Context.User = new GenericPrincipal(this.Context.User.Identity, roles);
                }
            }
        }
    }

此处，主要代码就是将Context.User.Identity强制转换为FormsIdentity类的对象，通过访问Ticket属性的UserData属性，获得被序列化后的对象的字符串，最后用方法Serialize.Decrypt<UserInfo>(strUser)将字符串反序列化成对象，再将UserInfo对象的Roles属性以“,”为分隔符分隔成角色数组，再用Context.User.Identity和角色数组生成一个新的GenericPrincipal对象，赋值给Context.User ，则Context.User 为已经设置好角色的验证对象。

按照我们的设置，Admin用户能访问两个目录，而User1用户，则只能访问ManageUsers一个目录。

第五步：集中管理Web.config文件

目录的访问权限控制，是按用户还是按角色，一般由具体业务决定。

但是，随着目录的增多，每个目录下都存在一个Web.config文件，管理起来特别不方便。

通过上面提到过的location节的path属性，我们可以实现Web.config配置的统一管理。我们可以将各个文件或目录的配置都放置在根目录的Web.config文件内，代码如下：

结尾：

这次彻底理顺FORM验证的过程，发现了不少实用性很强的技巧，中间参考了很多网友的文章，也通过Reflector看了一下具体实现的源代码。感觉收获不少，最大的收获就是对于问题不但要知其然更要知其所以然，要有一种打破沙锅问到底的净胜。

大家如果有什么问题有什么疑问，不但要找到解决的办法，有时间的话最好从理论到底层代码都好好过一过，对自己的水平长进有很大的帮助。

这篇文章还有很多方面没有涉及，也有很多高深的东西没有讲到，例如“通过PrincipalPermissionAttribute配合Forms验证进行基于角色或用户的安全验证”。就当留给自己一个研究的尾巴吧。

本文链接

从《钢铁侠2》看软件测试的重要性

2010-06-02T07:39:00Z

作为程序员的我，昨晚看完钢铁侠2，一路回来是感叹颇多。印象最深的还是片尾处，反派被击倒后，开始了自爆程序，然而此自爆程序的倒计时部分却存在明显的BUG，导致主角不但成功逃走甚至还有时间营救几公里开外的女友。更可恨的是，主角不但成功避开自爆，而且还和女友在楼顶边啃嘴边看自爆产生的烟花。这对对手是多大的打击啊……

作为反派的软件工程师，

他在编程能力上不可谓不强，片中他能在很短的时间内破解“hammer”公司的系统密码，从而登录系统可作为例证；

他在动手能力方面也非常强，片中他能在条件极其有限的情况下，制作出将正在比赛的赛车劈成两半的“神鞭”；

他在个人体力方面那不是一般的强，软件工程师通常是手无缚鸡之力，片中的他却能徒手将两个看守他的彪形大汉打倒，并悬吊在屋顶上，充分证明了他的体力的出众，再加上他那满是沧桑的脸庞，一个极具男人味的粗犷型软件工程师呼之欲出；

更难能可贵的是，他在系统的扩展性和思想的前瞻性方面以及风险预估和规避方面，做得也很强，片中，他在“钢铁战斗系统神鞭1.0版”的基础上扩展出了“钢铁战斗系统无人版”，而且他预见性的知道无人版的战斗系统是无法伤害主角的，于是他又给自己升级开发了“钢铁战斗系统神鞭2.0版”，甚至他也预见了2.0版的战斗系统还是打不过主角，于是他准备了“钢铁战斗系统自爆插件”。可见，他做为一个软件工程师，对整个工程的掌控是多么的完善。

可是最终，他还是没能赢过主角。为什么？

因为，自始至终反派的软件工程师没有对他的产品进行测试，原因可能是“hammer”公司的老总对他限制太多，导致了他没法测试，其二，他自己也过于自信，或者有点受粗犷型性格的影响，忽视了测试这一步。

反过头来我们再看主角，从第一集开始，主角是完全按照软件工程来开始一个产品研发了，有立项，有需求，有分析，有研发，最重要的是他有测试。不但有单元测试（第一集中，主角单个测试脚步的飞行控制，单个测试手部的能量发射系统等），还有整合测试（第一集中，将钢铁衣整合在一起进行各种飞行测试等），甚至有极端临界条件的测试（第一集中，飞到极度高空，测试在极度低温环境下的效能）。而在第二集中，主角为了找到替代能源，更是进行了多次的测试，直至找到后，还在进行稳定性的测试，只是在最后为形式所逼，测试过程没有完整走完，但基本的测试还是有的。

于是，反派在最后关头启动“钢铁战斗系统自爆插件”，但因为没有测试倒计时的那个模块，导致主角成功脱逃，自己也输了这场斗争。

由此可见，测试对于一个软件项目来说，是多么重要。没有测试，没有详尽的测试，交付给用户的系统就是充满不确定性不稳定性的系统，到最后，回过头来伤害的还是软件工程师本人和本团队。

本文链接

关于《asp.net下web控件点评》中的一些看法

2009-08-18T15:21:00Z

前不久看了园友的一篇文章《asp.net下web控件点评》，地址如下http://www.cnblogs.com/windinwing/archive/2009/08/17/1547803.html，主要是分析了一下web控件的优劣势。文章说的很在理，也引发了我的一些思考。这几天做一个网站，遇到一些里面所说的问题，大部分是和作者一样的烦恼，当然也有些不同的看法。文中的第四点如下： Title4.对...

【转】程序员的爱情

2008-06-26T02:02:00Z

我能抽象出整个世界．．．但是我不能抽象出你．．．因为你在我心中是那么的具体．．．所以我的世界并不完整．．．我可以重载甚至覆盖这个世界里的任何一种方法．．．但是我却不能重载对你的思念．．．也许命中注定了你在我的世界里永远的烙上了静态的属性．．．而我不慎调用了爱你这个方法．．．当我义无返顾的把自己作为参数传进这个方法时．．．我才发现爱上你是一个死循环．．．它不停的返回对你的思念压...

【转】SQL Server数据库开发的二十一条军规

2008-06-13T06:03:00Z

无意中看到这篇文章，觉得挺好的，就转过来自己收了。如果你正在负责一个基于SQL Server的项目，或者你刚刚接触SQL Server，你都有可能要面临一些数据库性能的问题，这篇文章会为你提供一些有用的指导(其中大多数也可以用于其它的DBMS)。在这里，我不打算介绍使用SQL Server的窍门，也不能提供一个包治百病的方案，我所做的是总结一些经验----关于如何形成一个好的设计。这些经验...

VS.net2008正式版发布了

2007-12-28T06:00:00Z

2008Beta2版也试用了一段时间，最近比较忙一直没时间捣鼓这个，再一上网就发现正式版已经发布了，不过是英文版带90天限制的。下面是微软官网的下载页面地址：http://www.microsoft.com/downloads/details.aspx?FamilyID=83c3a1ec-ed72-4a79-8961-25635db0192b&DisplayLang=en突破90天使用限制...

VS2005的关于母版页嵌套的一个小技巧

2007-08-02T08:17:00Z

最近工作很忙，无法更新设计模式的读书笔记，几乎没有时间看书。真实罪过啊……不过工作当中还是很有收获的。2005新上岗了。慢慢的也开始熟悉了它的用法。其中提供的母版页技术，是个相当实用的东西。大大简化了编程的手段，减少了工作量。随着使用的深入，开始使用母版页嵌套的技术。不过这个东西好，但是一直有一个比较困扰开发人员的地方。那就是：使用母版页嵌套，无法切换到视图界面进行编辑，在...

博客园_〖老四〗的技术空间-All For Better Codes

关于MVC权限控制的一点小想法

推荐百度地图的新功能--“三维”

jQuery UI 应用不同Theme的办法

Asp.Net实现FORM认证的一些使用技巧

从《钢铁侠2》看软件测试的重要性

关于《asp.net下web控件点评》中的一些看法

【转】程序员的爱情

【转】SQL Server数据库开发的二十一条军规

VS.net2008正式版发布了

VS2005的关于母版页嵌套的一个小技巧