开发笔记 第533页

简介

ACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：原子性（Atomicity）、一致性 （Consistency）、隔离性（Isolation）、持久性（Durability）.这是可靠数据库所应具备的几个特性.下面针对这几个特性进 行逐个讲解.

理解原子性(Atomicity)

原子性意味着数据库中的事务执行是作为原子。即不可再分，整个语句要么执行，要么不执行。

在SQL SERVER中，每一个单独的语句都可以看作是默认包含在一个事务之中:

所以，每一个语句本身具有原子性，要么全部执行，这么全部不执行，不会有中间状态:

上面说了，每一条T-SQL语句都可以看作是默认被包裹在一个事务之中的,SQL Server对于每一条单独的语句都实现了原子性，但这种原子粒度是非常小的，如果用户想要自己定义原子的大小，则需要包含在事务中来构成用户自定义的原子粒度:

对于用户来说，要用事务实现的自定义原子性往往是和业务相关的，比如银行转账，从A账户减去100，在B账户增加100，如果这两个语句不能保证原子性的 话，比如从A账户减去100后，服务器断电，而在B账户中却没有增加100.虽然这种情况会让银行很开心，但作为开发人员的你可不希望这种结果.而默认事 务中，即使出错了也不会整个事务进行回滚。而是失败的语句抛出异常，而正确的语句成功执行。这样会破坏原子性。所以SQL SERVER给予了一些选项来保证事务的原子性.

SQL SERVER提供了两大类方式来保证自定义事务的原子性：

1.通过SET XACT_ABORT ON来设置事务必须符合原子性

利用设置XACT_ABORT选项设置为ON,来设置所有事务都作为一个原子处理.下面例子利用两个语句插入到数据库，可以看到开启SET XACT_ABORT ON选项后，事务具有了原子性:

2.按照用户设置进行回滚(ROLLBACK)

这种方式具有更高的灵活性，开发人员可以自定义在什么情况进行ROLLBACK,利用TRY CATCH语句和@@ERROR进行判断都属于这种方式.

理解一致性(Consistency)

一致性,即在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。

一致性分为两个层面

1.数据库机制层面

数据库层面的一致性是，在一个事务执行之前和之后，数据会符合你设置的约束（唯一约束，外键约束,Check约束等)和触发器设置.这一点是由SQL SERVER进行保证的.

2.业务层面

对于业务层面来说,一致性是保持业务的一致性.这个业务一致性需要由开发人员进行保证.很多业务方面的一致性可以通过转移到数据库机制层面进行保证.比如，产品只有两个型号，则可以转移到使用CHECK约束使某一列必须只能存这两个型号.

理解隔离性（Isolation)

隔离性。事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。

在Windows中，如果多个进程对同一个文件进行修改是不允许的，Windows通过这种方式来保证不同进程的隔离性:

而SQL Server中，通过SQL SERVER对数据库文件进行管理，从而可以让多个进程可以同时访问数据库:

SQL Server利用加锁和阻塞来保证事务之间不同等级的隔离性.

一般情况下，完全的隔离性是不现实的，完全的隔离性要求数据库同一时间只执行一条事务，这样的性能可想而知.想要理解SQL Server中对于隔离性的保障，首先要了解事务之间是如何干扰的.

事务之间的互相影响的情况分为几种，分别为:脏读(Dirty Read)，不可重复读，幻读

脏读

脏读意味着一个事务读取了另一个事务未提交的数据,而这个数据是有可能回滚的:

下面来看一个例子:

两个事务，事务A插入一条数据，但未提交，事务B在此期间进行了读取，读取到了事务A未提交的数据，造成脏读

不可重复读(Unrepeatable Read)

不可重复读意味着，在数据库访问中，一个事务范围内两个相同的查询却返回了不同数据。这是由于查询时系统中其他事务修改的提交而引起的。

下面来看一个不可重复读的例子:

事务B中对某个查询执行两次，当第一次执行完时，事务A对其数据进行了修改。事务B中再次查询时，数据发生了改变:

幻读(phantom read)

幻读,是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这 个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样.

下面来看一个例子:

事务B更新表中所有的数据，在此期间事务A插入了一条数据，事务B再次查询后，发现居然还有没有修改的数据，产生幻读:

理解SQL SERVER中的隔离级别

为 了避免上述几种事务之间的影响,SQL Server通过设置不同的隔离等级来进行不同程度的避免。因为高的隔离等级意味着更多的锁，从而牺牲性能.所以这个选项开放给了用户根据具体的需求进行 设置。不过默认的隔离等级Read Commited符合了99%的实际需求.

SQL Server隔离事务之间的影响是通过锁来实现的，这个概念比较繁杂，所以本文不会详细对这个概念进行讲解.通过阻塞来阻止上述效果

SQL Server提供了5种选项来避免不同级别的事务之间的影响

隔离等级由低到高分别为

Read Uncommited(最高的性能，但可能出现脏读，不可重复读，幻读)

Read commited(可能出现不可重复读，幻读)

Repeatable Read(可能出现幻读)

Serializable(最低的性能，一次只能执行一个事务，但避免了上述所有情况)

SNOPSHOT(这个是通过在tempDB中创建一个额外的副本来避免脏读，不可重复读，会给tempDB造成额外负担，因为不是标准ANSI SQL标准，不详细讨论)

总之，不同的隔离级别是通过加不同的锁，造成阻塞来实现的，来看一个例子:

SQL SERVER通过阻塞来阻止脏读，所以保持独立性会以付出性能作为代价：

理解持久性（Durability)

持久性，意味着在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

即使出现了任何事故比如断电等，事务一旦提交，则持久化保存在数据库中.

SQL SERVER通过write-ahead transaction log来保证持久性。write-ahead transaction log的意思是，事务中对数据库的改变在写入到数据库之前，首先写入到事务日志中。而事务日志是按照顺序排号的（LSN）。当数据库崩溃或者服务器断点 时，重启动SQL SERVER，SQL SERVER首先会检查日志顺序号，将本应对数据库做更改而未做的部分持久化到数据库，从而保证了持久性.

总结

本文简单讲述了ACID的概念和ACID在SQL SERVER中的实现.ACID只是一个理念，并不是某项具体的技术.对于健壮数据库来说，保证ACID是可靠数据库的前提.

无聊中手机上网翻到的，先没明白这是什么东西，等我实际体验了一把以后完全震惊了，太给力了！

NuGet的官方说明是：NuGet是一款Visual Studio的扩展，它可以简单的安装、升级开源库和工具。

官网地址：http://www.nuget.org/

官网最醒目的位置就是下载链接，安装完成后我们来快速体验一把。

手上有个小项目需要使用到json格式，一般情况我会先Google一下有没有相关的开源库（这个肯定是有的）。

然后从一些博文中发现了Json.net，然后继续Google之，找到Json.net的官网，然后下载最新的稳定版本，找出DLL文件引用它。

是不是很复杂？很繁琐？（其实没用NuGet之前我一直觉得这样干很方便的）

使用NuGet我们就可以很快搞定了。

右键Managet NuGet Packages

搜索json，然后看看结果和右侧的介绍，Json.net排在第一位，点Install安装。

然后等待下载完成，可以看到引用里面已经有了Json.net了。

那么NuGet到底干了什么呢？下载的开源库在何处呢？看一下输出结果就知道了。

在packages文件夹下可以找到相关dll文件。

还有命令行模式可以选用

还是以Json.net举例，输入Install-Package Newtonsoft.Json即可。

NuGet还有一个优势就是可以处理依赖（我个人觉得Net的依赖复杂程度没有java麻烦）。以Spring.Core为例子，它依赖Common.Logging。

自然NuGet完美解决了。

我没有试升级库功能，但是个人感觉NuGet还是有一些局限的。

首先需要联网，其次是每次都下载新的，而且会把针对不同.Net版本的都down下来。

写这个文章，主要是因为网上对C#字符串和享元模式的误解比较多。

Flyweight模式

先说这名字，fly呢，就是苍蝇，没错这里面不是飞的意思，是苍蝇的意思，weight大家都知道，就是重量，苍蝇的重量，就是非常非常轻的意思。所以Flyweight模式就是处理非常非常轻量级对象的一个东西。

Flyweight的目标是解决大量细粒度对象的内存消耗问题，当然，巧妇难为无米之炊，任何模式和手法都不能凭空造出内存来，所以享元模式针对的情况是这些细粒度对象的中数据有重复的情况。

Flyweight的做法是，把对象的状态（通常用属性表示），分成两个部分，一部分是内部状态，另一部分是外部状态。内部状态是不易重复的（或者说必要的），外部状态是易重复的。所以，Flyweight把外部状态提取出来共享，这样就一定程度解决了内存占用问题。

C#中的字符串不是Flyweight模式

在网上常常可以看到一个说法，说C#中的字符串使用了Flyweight模式，开门见山地说，这个说法是错误的。

错在哪里呢？按照上文的介绍，错就错在字符串它没有所谓的“内部状态”。

通常讲字符串是享元的原因就是以下代码：

string a = “Hello World”;
Console.WriteLine(Object.ReferenceEquals(a, “Hello World”)); //True

当使用字符串直接量的时候，不论你写了多少个”Hello World”，最终内存里面只有一个字符串对象。

运行时创建的字符串并不在此列，可以使些手段，强制在内存里面产生新的字符串。

string a = “Hello World”;
Console.WriteLine(Object.ReferenceEquals(a, new String(“Hello World”.ToCharArray())));  //False

因为我们强行调用了new，所以这个字符串跟内存中的直接量”Hello World”对应的对象不是同一个。

有趣的是，C#还允许强制把一个字符串加入到（如果已经有了，就只是找出来）字符串池里面。

string a = “Hello World”;
string b = String.Intern(new String(“Hello World”.ToCharArray()));
Console.WriteLine(Object.ReferenceEquals(a,b) );

或者

string a = String.Intern(new String(“Hello World”.ToCharArray()));
string b = String.Intern(new String(“Hello World”.ToCharArray()));
Console.WriteLine(Object.ReferenceEquals(a,b) );

前面提到了，这个行为跟Flyweight使用的内部状态和外部状态不同，是两个对象实实在在就是同一个对象。

C#中的字符串与Flyweight模式

好吧，前面说了不少，C#中的字符串不是Flyweight模式，但是是不是就意味着C#里面字符串跟Flyweight没有关系呢？

当然不是，否则我写这么一篇文章岂不是太蛋疼了……

字符串池和Intern方法简直是实现Flyweight的神器啊！

考虑我们有某一类对象，可能会创建几百万个，对象里面恰巧有这么一个属性叫做颜色，它在对象构造的时候随机产生，颜色用的是rgb色，用rgb24来表示，于是颜色字符串类似#ccc这样子。

代码写起来就像下面的样子：

    class Element
    {
	static Random rnd = new Random();
	static char[] table;
	static Element() 
	{
	    table = "0123456789abcdef".ToCharArray();
	}

	public string color;
	public Element()
	{
	    color = "" + table[rnd.Next() % 16] + table[rnd.Next() % 16] + table[rnd.Next() % 16];
	}
    }

接下来我们创建3千万个对象看看如何

	    Element[] eles = new Element[30000000];
	    for (var i = 0; i < 30000000; i++)
	    {
		eles[i] = new Element();
	    }

从任务管理器看到一大块内存被吃掉了

接下来我们使用String.Intern来实现Flyweight：

    class Element
    {
	static Random rnd = new Random();
	static char[] table;
	static Element() 
	{
	    table = "0123456789abcdef".ToCharArray();
	}

	public string color;
	public Element()
	{
	    color = String.Intern("" + table[rnd.Next() % 16] + table[rnd.Next() % 16] + table[rnd.Next() % 16]);
	}
    }

同样来看看运行结果：

可以看到内存占用量的明显变化。

因为字符串对象的不可更改性质，使用了String.Intern之后，我们完全看不出前后color的区别，也就是说，修改前后的Element类是完全等效的，但是Flyweight为我们节约了大量的内存。

更多思考

这个典型的使用flyweight场景为我们揭示了享元外部状态的特征：像字符串一样不可更改的对象。GoF原书的例子中的字型对象Glyph也是如此。

String.Intern这种对象池的方式实现flyweight也值得借鉴，我们可以考虑自己设计flyweight的外部状态对象时使用类似的方式。

Protocol Buffers 是在一个很理想的结构化数据的语言中立的序列化格式。你可以考虑一下XML或JSON，但更轻，更小的协议缓冲区。 这种格式的广应用于谷歌不同的系统之间交换数据。

由于其结构化数据的最佳表现，protocol buffers 是一个代表RESTful服务处理的数据很好的选择。要遵循REST的原则， protocol buffers 应作为一个新的超媒体类型的代表。 在当前版本（.NET 4) 的Windows通讯基础（WCF），包含一个新的媒体类型，需要相当数量的努力。 幸运的是，新版本的WCF HTTP堆栈，使媒体类型的WCF编程模型的一等公民，大家可以Glenn Block’s 博客去了解更详细的内容。推荐大家假期可以看下这本书《REST实战》http://book.douban.com/subject/6854551/

下面我们来介绍如何使用Google Protocol Buffers，只定义一个超媒体类型 ProtoBufferFormatter：

自 定义超媒体类型是通过创建自定义的MediaTypeFormatter，实现OnWritetoStream() 和 OnReadFromStream() 方法进行序列化和反序列化处理。人们经常认为媒体类型只是在服务端使用，但是它用来在客户端控制序列化和反序列化的要求，下图显示了一个HTTP 请求/响应和媒体类型格式化扮演的角色：

这个例子我们使用入门：构建简单的Web API 的代码和WCF Web API Preview 6。使用的媒体类型是application/x-protobuf ，REST服务的核心原则就是服务器和客户端之间的松耦合性，客户端需要知道书签的URI，但不应该知道任何其他的URI的知识，但是客户端必须知道链接关系。

下面的代码是自定义的ProtoBufferFormatter，构造函数里指明了支持的媒体类型 application/x-protobuf。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Net.Http.Formatting;
using System.IO;
using ProtoBuf;
using ProtoBuf.Meta;

namespace WcfWebFormat.Formatters
{
public class ProtoBufferFormatter : MediaTypeFormatter
{
public ProtoBufferFormatter()
{
this.SupportedMediaTypes.Add(new System.Net.Http.Headers.MediaTypeHeaderValue(“application/x-protobuf”));
}

protected override void OnWriteToStream(Type type, object value, Stream stream, System.Net.Http.Headers.HttpContentHeaders contentHeaders, System.Net.TransportContext context)
{
Serializer.Serialize(stream, value);
}

protected override object OnReadFromStream(Type type, Stream stream, System.Net.Http.Headers.HttpContentHeaders contentHeaders)
{
object obj = (RuntimeTypeModel.Default).Deserialize(stream, null, type);
return obj;
}

}
}

如上所示，我们在OnWriteToStream方法中将.NET对象序列化为ProtoBuf格式，在OnReadFromStream方法中将ProtoBuf格式饭序列化为.NET对象。

现在需要给我们的.NET对象加入ProtoBuf 序列化的标签：

using System.Collections.Generic;
using System.Xml.Serialization;
using ProtoBuf;

namespace ContactManager.Resources
{
[ProtoContract]
public class Contact
{
[ProtoMember(1)]
public int ContactId { get; set; }
[ProtoMember(2)]
public string Name { get; set; }
}
}

把ProtoBufferFormatter 加入到WCF运行时的超媒体类型集合里。

using Microsoft.ApplicationServer.Http;
using WcfWebFormat.Formatters;

namespace ContactManager
{
public class ContactManagerConfiguration : HttpConfiguration
{
public ContactManagerConfiguration()
{
this.Formatters.Add(new ProtoBufferFormatter());
}
}
}

修改服务配置，使用ContactManagerConfiguration：

var config = new ContactManagerConfiguration() { EnableTestClient = true };
routes.Add(new ServiceRoute(“api/contacts”, new HttpServiceHostFactory() { Configuration = config }, typeof(ContactsApi)));

在客户端调用的代码如下：

var serviceUri = new Uri(“http://localhost:9000/api/contacts/”);
var httpClient = new HttpClient();
httpClient.BaseAddress = serviceUri;
httpClient.DefaultRequestHeaders.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue(“application/x-protobuf”));

var response = httpClient.GetAsync(“1”).Result;
Contact obj = (RuntimeTypeModel.Default).Deserialize(response.Content.ReadAsStreamAsync().Result, null, typeof(Contact)) as Contact;

var formatters = new MediaTypeFormatterCollection() { new ProtoBufferFormatter() };
var content = new ObjectContent<Contact>(obj, “application/x-protobuf”,formatters);
content.Headers.ContentType = new MediaTypeHeaderValue(“application/x-protobuf”);

httpClient.PostAsync(serviceUri,content);

即使目前来说Google Protocol Buffers没有XML/JSON那样普及，RESTful服务使用中ProtoBuf无疑是一个非常有效的超媒体类型。祝大家龙年新春愉快，吉祥如意！

相关文章：

• 软件系统开发中的数据交换协议
• .net自带二进制序列化，XML序列化和ProtoBuf序列化的压缩对比
• Android上GTalk以及Push机制的XMPP数据选择使用protobuf格式而非XML
• Leverage T4Scaffolding for WCF Web API
• using-protocol-buffers-on-net-platform-part-i
• using-protocol-buffers-on-net-platform-part-ii
• Restful WCF / EF POCO / UnitOfWork / Repository / MEF : 1 of 2

上面一篇文章我们简单介绍了一个一级菜单的应用。

在实际的设计中菜单的的信息基本存储在sitemap的xml文件中，菜单还涉及到权限问题。

本章将介绍并举例说明如何设计基于规则的MVC应用程序的安全性。

基于角色的授权

在计算机系统的安全，基于角色的访问控制（RBAC）是一个系统访问限制授权用户的方法。在一个组织内，角色创建的各项工作职能。来执行某些操作的权限分配给特定的角色。
业务上我们必须定义一套针对不同的业务功能的角色体系，例如管理员，数据管理员，普通用户的角色… …

基于规则的访问控制

以规则为基础的授权框架，一般利用XML文档存储简单的规则设置,来控制系统访问权限。(也可以存储在数据库中，读者可以扩展Enterprise Library)

请参见下面的例子。

<rules>
    <add expression="R:Administrator" name="IsAdministrator" />
     <add expression="R:Administrator OR R:DataSteward" name="IsDataSteward" />
     <add expression="R:User OR R:DataSteward OR R:Administrator"  name="IsUser" />
 </rules>

规则“IsAdministrator”会检查当前用户是否有Administrator的角色。 “IsUser”将对角色User, DataSteward或者Administrator都有效。

SecurityHelper

SecurityHelper类利用了Enterprise Library 的默认的AuthorizationRuleProvider,它是我们整个系统的权限核心。主要代码如下。

其中对当前用户检查某个规则的有效性代码如下。

菜单的访问控制

在Web.sitemap文件中我们对每个节点增加一个属性，AuthorizationRule这样菜单和用户角色就关联起来了。

<?xml version="1.0" encoding="utf-8" ?>
<siteMap enableLocalization="true">
  <siteMapNode title="Menu">
    <siteMapNode controller="Home" title="Home"    action="Index" resourceKey="Tab_Home" AuthorizationRule="IsUser"/>
    <siteMapNode controller="Customer" title="Manage Customers"    action="Index" resourceKey="Tab_ManageCustomers" AuthorizationRule="IsDataSteward"/>
    <siteMapNode title="Switching Brands" resourceKey="Tab_SwitchingBrands" AuthorizationRule="IsUser">
      <siteMapNode title="Violin" controller="Home" action="SetTheme/Violin"  AuthorizationRule="IsUser"/>
      <siteMapNode title="Mack" controller="Home" action="SetTheme/Mack" AuthorizationRule="IsUser"/>
      <siteMapNode title="Mack Dual" controller="Home" action="SetTheme/MackDual" AuthorizationRule="IsUser"/>
      <siteMapNode title="Renault" controller="Home" action="SetTheme/Renault"  AuthorizationRule="IsUser"/>
      <siteMapNode title="Volvo BA" controller="Home" action="SetTheme/VolvoBA" AuthorizationRule="IsUser"/>
      <siteMapNode title="Volvo Group" controller="Home" action="SetTheme/VolvoGroup" AuthorizationRule="IsUser"/>
    </siteMapNode>
  </siteMapNode>
</siteMap>

菜单的规则如何、什么时候被加载呢？在渲染菜单的SiteMapBinding.cshtml文件中，我们的代码如下。(示例利用了Telerik for ASP.NET MVC控件)

@using Volvo.CustomerMaster.Web.Common.Security
@using Volvo.CustomerMaster.Web

 @{ Html.Telerik().Menu()
        .Name("Menu")
        .BindTo("Web",(item, node) =>{
             if (node.Attributes["resourceKey"] !=null)
                item.Text = UI_Resources.ResourceManager.GetString(node.Attributes["resourceKey"] as string) ?? item.Text;
            if(node.Attributes["imageurl"] != null)
            item.ImageUrl = node.Attributes["imageurl"].ToString();
            item.Visible = SecurityHelper.Authorized(node.Attributes["AuthorizationRule"].ToString());
        })
         .Effects(fx =>
          fx.Toggle()
          .OpenDuration(200)
          .CloseDuration(200))
       .Render();
 }

其中item.Visible=SecurityHelper.Authorized(node.Attributes[“AuthorizationRule”].ToString());这行代码就决定了菜单的可见性由我们定义的规则控制。

UI元素访问控制

利用同样原理，按钮的enable/disable也可以基于规则来控制。我们首先构造一个类 (HtmlHelper)用于在页面上显示按钮。

ButtonHelper

以下核心代码将权限规则和按钮的显示关联。

Button

在页面中，我们如何利用ButtonHelper呢？下面的例子利用Telerik来显示一个Grid,在Grid的头上我么将显示edit, add, delete 按钮。

按钮的生成就利用了我么的ButtonHelper类。它提供了一些扩展方法。

@(Html.Telerik().Grid<Customer>()
         .Name("CustomerGrid")
         .EnableCustomBinding(true)
         .DataBinding(bind => bind.Ajax().Select("ListCustomerAjax", "Customer"))
         .ToolBar(toolBar => toolBar.Template
          (
             @Html.Button("toolbarEditRow", UI_Resources.ListCustomer_EditCustomerButton, 
             ButtonHelper.SetButtonDisability("toolbarEditRow", "IsAdministrator"), 
             new { title = UI_Resources.ListCustomer_EditCustomerButtonTooltip, @class = "icon edit" })
             +"<span >&nbsp;</span>"+
             @Html.Button("toolbarAddRow", UI_Resources.ListCustomer_AddNewCustomerButton, ButtonHelper.SetButtonDisability("toolbarAddRow", "IsAdministrator"), new { title = UI_Resources.ListCustomer_AddNewCustomerButtonTooltip, @class = "icon add" })
             +"<span >&nbsp;</span>"+
             @Html.Button("toolbarDeleteRow", UI_Resources.ListCustomer_DeleteCustomerButton, ButtonHelper.SetButtonDisability("toolbarDeleteRow", "IsAdministrator"), new { title = UI_Resources.ListCustomer_DeleteCustomerButtonTooltip, @class = "icon delete" })
          ))
         .Columns(columns =>
                    {
                        columns.Bound(o => o.Number).Title("Number").Width(40);
                        columns.Bound(o => o.Name).Title("Name").Width(100);
                        columns.Bound(o => o.Address).Title("Address").Width(100);
                    }
                 )
        .ClientEvents(x => x.OnLoad("CustomerGrid_OnLoad"))
        .Selectable()
        .Pageable(paging => paging.PageSize(10).Total(Model.CustomerCount))
        .Sortable())

显示按钮的时候，我们调用了ButtonHelper.SetButtonDisability来控制按钮的enable/disable状态，我们也可以通过它来控制显示、不显示按钮。

MVC Controller类的访问控制

有些用户可能会直接在浏览器中输入URL来绕过菜单的权限控制，我们必须在MVC的Controller级别加上我们的基于规则的权限管理。

我们增加一个新的类RuleAuthorizeAttribute,它继承于System.Web.Mvc.AuthorizeAttribute

View Code

代码很简单，它也利用了我们前面提到的SecurityHelper类的功能。

我们把这个属性设置的示例程序中的CustomerController类中。

    [HandleError]
    [RuleAuthorize(Allow="IsDataSteward")]
    public class CustomerController : BaseController
    {
        public ICustomerService CustomerService { get; set; }

        public CustomerController(ICustomerService customerService)
        {
            CustomerService = customerService;  
            
        }

假设我们登录的用户没有DataSteward或Administrator角色，但是他尝试直接在浏览器里面输入URL:http://localhost:2967/Customer。

新增的Filter控制了直接URL的权限管理。

按钮显示的控制

———————————————————————-
示例代码.

http://files.cnblogs.com/huyq2002/Sample.zip

运行程序您需要生成数据库CustomerMaster,运行CustomerMaster.SQL,同时修改NHibernate.config中的connection.connection_string

系统适用于域认证，也很容易扩展到其他认证方式，如form认证等

通过改变代码中的UserService的GetUser方法可以模拟不同的角色来使用系统

// 2. Get roles defined for the user
            if (userName.Equals("v0cn174", StringComparison.CurrentCultureIgnoreCase))
            {
                //user.AddRole(new UserRole(UserRoleConstants.Administrator));
                user.AddRole(new UserRole(UserRoleConstants.DataSteward));
                //user.AddRole(new UserRole(UserRoleConstants.User));
            }
            else
            {
                // All users are superusers in this mock
                //user.AddRole(new UserRole(UserRoleConstants.Administrator));
                //user.AddRole(new UserRole(UserRoleConstants.DataSteward));
                user.AddRole(new UserRole(UserRoleConstants.User));
            }
            return user;