WPF, WPF/E释疑

什么是WPF,经常看博客堂以及博客园的朋友,我相信眼睛都快磨出茧子来了。WPF嘛,就是现在称之为Windows Presentation Foundation,小名叫Avalon的那个东东,为了更好的实现Windows Vista体验的基础层架构,是.NET 3.0的一部分。如果一句话以蔽之,就是一个更有生产力的、更统一的用来管理用户界面、文档及多媒体等的模型。再仔细说说,更有生产力就是指开发丰富实用外观不费劲,易于快速开发,而更统一则是指开发B/S以及C/S可XAML方式以统一知识域,不需要分而化之。

讲到WPF,就要提到XAML,XAML是WPF的声明性语言,提供对界面、文档以及多媒体等界面层逻辑的渲染。而且XAML可以直接在IE中打开(如右图)。同时,还有一种XBAP方式(如左图),也可以在IE中打开。两者会有一些异同,这在下面会做表述。

那么WPF/E呢,可能知道者就比较少了。这里面的E是指的Everywhere,也就是可以让WPF到处可以运行。我们知道,WPF本身是WinFX也就是现在的.NET 3.0的一部分,所以想要运行WPF,客户端必须安装.NET 3.0,而.NET 3.0的安装条件是Windows XP、Windows Vista、Windows Server 2003、Windows Longhorn Server之四大金钢。那么你如果想让WPF到处可以运行,就必须首先做到.NET可以到处安装。虽然说有专家预计在Windows Vista推出24月之内,全球会有2亿用户会使用上已经内置.NET 3.0的OS。但还有很多兄弟们仍然战斗在其它操作系统、其它浏览器、其它设备上,如何让这些兄弟们可以共享WPF之乐呢?这就是WPF/E。

而WPF/E,小名Jolt,目前正在紧锣密鼓的开发当中,一些细节尚未披露,目前可以知道的是它是使用Javascript来实 现,用来使其可以跨平台、跨浏览器、跨设备来使用。它也同样采用有些异构化的XAML来编写(主要添加了一些特殊的Javascript标记)。

对于开发人员来说,喜欢究根问底。这些方式,.EXE, .XAML,.XBAP还有WPF/E到底有何异同?在各种场合下面应该如何使用呢?我相信很多人会非常好奇。虽然看了很多DEMO,相信也有一些朋友在一些细节上还是有很多模糊。在青岛的时候,我做了下面这个表(当时展波兄也通过越洋电话提供免费支持),希望对大家有帮助。

.EXE XAML XBAP WPF/E
IE宿主运行 No Yes Yes Yes
支持其它浏览器 No No No Yes
支持其它操作系统 No No No Yes
跨设备 No No No Yes
支持业务逻辑 Yes No Yes Yes
需要.NET 3.0 Yes Yes Yes No

 

希望对大家理解这些概念有所帮助。

补记:关于.NET 3.0的命名,我个人总觉得是一个败笔,因为.NET 3.0必须依赖于.NET 2.0的存在,没有.NET 2.0,则无法使用.NET 3.0,所以可以说.NET 3.0=.NET 2.0+WPF+WCF+WWF+WCS+…。同时原计划中的3.0有可能会被命名为3.5,而3.5倒不必依赖于3.0了,不然就没完没了了。据说当初之所以改名字是怕别人混淆,怎么刚推完.NET,又开始推WinFX了?归纳到同一品牌下我没有异议,但突然直接升级为3.0,倒使得此事有些让人混淆了,甚至有些同事至今都分不清WinFX与.NET 3.0的区别。

Web 2.0与流氓软件

究竟什么样的网站叫做Web 2.0,目前业界的情况是见仁见智,尚无人给出一个标准并且得到业界公认的定义,只能通过界定的方式来给出。下图就是维基百科(如果您没有安装代理服务器,不必要浪费精力尝试访问此网站了)中给出的三项基本原则。

OK,对于这三项基本原则中的前两项我基本上没有异议,而且我给出了一个简单的总结,即Web 2.0的网站应该是开放而且可供大家分享的。但关于“平台”部分,即“完全地基于Web-大多数成功的Web 2.0网站可以几乎完全通过浏览器来使用”,开心却有不同的见解。

为什么呢?我们知道,在Web 1.0或者Web 1.x最热火朝天的时候,经济学家们拿出一个专用名词即“眼球经济”。为了吸引用户的眼球,各大网站无所不用其极,为了PV的增长而使用各种手段。当历史进入到Web 2.0时期,“眼球经济”让位给“指尖经济”,从使用网站编辑编写精彩的内容以吸引读者的眼球,逐渐转变为提供丰富实用的平台,以吸引用户的指尖,共同创造内容,从而增加用户忠诚度,创造更大的利润。

流氓软件就是Web 1.x时代的产物,就是“眼球经济”的遗产。国内的部分网站为了吸引流量,而不惜在夜路上使用流氓劫道,打着方便用户的名义来劫持用户,在违背用户意义的情况下,为网站主人创造流量甚至其它的经济利益。

到了Web 2.0时代,我们如果提倡“完全地基于Web-大多数成功的Web 2.0网站可以几乎完全通过浏览器来使用”,是不是就可以让这些不请自来的流氓软件扫地出门了呢?我看不见得吧。毕竟虽然Web 2.0喊得火热,我们还处于一个流氓横行的时代,甚至有些流氓还是某些Web 2.0的新贵,所以无论是哪一代的Web,如果只是固守Web平台,完全使用浏览器来访问,可谓不可持久矣。

诸君如果查看前段时间的新闻,会发现很多关于Web 2.0泡沫期已到,大批VC撤资的报导。泡沫为什么会出现,就因为网站没有根基,没有根基就注定会雪崩,所以一个网站不能只靠Web平台,我们应该去占领用户的客户端,将Web延伸到用户的客户端,增加Web 2.0平台对于用户的黏度,未来才会是光明的。B/S与C/S的渐进整合,应该就是Web 3.0吧?

当然,我不是在这儿鼓励大家去编写流氓软件,以遗臭万年。有兴趣的话,为什么不编写一些绅士软件呢,真正的吸引用户从桌面来参与到网站创造价值呢?比如类似于Windows Live Writer?或者Word 2007中的博客发布功能?或者是Outlook 2007, IE 2007, Vista Sidebar中的RSS Reader?

都Web 2.0了,别把用户的电脑当作流氓混战的场地。

九月份Atlas控件工具包发布(现支持动画效果)

【原文地址】September Atlas Control Toolkit Released (Now with Animation Support)
【原文发表日期】 Tuesday, September 19, 2006 8:28 AM

Atlas控件工具包的最新版已于上个星期晚些时候推出。这个工具包基于核心ASP.NET AJAX 运行时,是个提供了很多有用的具备AJAX功能的ASP.NET控件库。你可以在这里下载和运行样本程序

就象我在以前的帖子里提到的那样,这个工具包很酷的地方就在于,它包含了几个由非微软开发人员提供的控件。例如,在这个更新版本里,有一个非常酷的新Slider控件(点击这里观看它的实战演示),就是由非微软开发人员贡献的,它提供了非常平滑的,在客户端从数值范围选值的支持:

这个版本里还包括了对一些渐为时兴的客户端动画效果的支持。你可以直接在JavaScript里使用动画效果包,或者通过<atlasToolkit:AnimationExtender>控件来轻易地组合动画行为,以响应用户的动作。譬如,你可以让文字和图片渐现,扩大,爆炸,移动,或pop-up等等。

动画效果包很酷的地方在于,你可以通过<atlas:AnimationExtender>控件,用声明的方式来定义动画行为,这使得定义动画顺序起来既干净又不费力。

你可以在这里进一步研究这个新的动画效果包,同时也能在线运行相关演示。务必查阅一下动画效果包的参考页,以深入学习动画效果类框架,以前它支持的所有的方法,属性和事件。

除了响应用户点击或客户端行为触发动画效果以外,你也可以在用ASP.NET AJAX UpdatePanel控件刷新部分页面做的postback时,使用新的<AtlasToolkit:UpdatePanelAnimationExtender>控件来添加动画效果的支持。这可以使得突出显示变化了的界面的方式更干净,更加对用户友好,譬如,你可以逐渐显示那些变化,或者真想出奇的话,你可以旋转/加彩变化了的界面,让你的用户看了都会晕眩。看一下UpdatePanelAnimationExtender的这个在线演示,深入研究一下这个控件。Alan Le在这里贴了一个很棒的简单例子,给你演示怎么通过这个控件用声明的方式组合动画,你应该去看一下。

一如既往,你可以免费下载带有全部源码的Atlas控件工具包,也可以在线运行它。想进一步学习使用ASP.NET AJAX(即Atlas)以及控件工具包的话,读一下我几个星期前写的这篇博客帖子,内含一堆很棒的免费录像的链接。

希望本文对你有所帮助,

Scott

标签:,
 

(思归译)

技巧和诀窍:在VS 2005里使用Vista的IIS7

【原文地址】Tip/Trick: Using IIS7 on Vista with VS 2005
【原文发表日期】 Tuesday, September 19, 2006 7:41 AM

上个星期,几个人都询问我怎么在Windows Vista上使用VS 2005 建立IIS7上的网站。具体来说,他们都遇到了一个问题,在试图连接IIS7时,他们要么看到一个对话框要求他们安装FrontPage服务器扩展,要么得到一个“你必须是管理员组的成员”的出错消息,如下图所示:

Bradley发表了 一个很好的帖子,描述了如何使得VS 2005连接到IIS 7.0的详细步骤。简短地说,你需要按下面二个步骤进行:

1) 你需要确认在IIS7里安装了可选的IIS 6 Management Compatibility(IIS 6管理兼容)这个选项。这将为新的配置系统安装一个与VS 2005使用的老的Metabase API相兼容的API。你可以在Vista 控制面板中的Turn Windows Features on or Off(打开/关闭Windows特性)对话框里选择该选项:

 

2) 你需要确定以高级权限来运行VS 2005,这样你才能有管理权限连接到IIS。如果要调试一个服务,或者创建网站或者改动影响整个机器的配置时,你需要拥有管理权限。具体做法是,在启动VS时,右击VS图标,然后选择“以管理员身份运行(Run as Administrator)”:

注意,假如你启动了UAC(用户访问控制)的话(注:UAC在Vista中默认是启动的),即使你的用户账号已经是管理员组成员,你还是需要这么做。如果你禁止了UAC(你可以通过控制面板来这么做),那么这第二步就不需要了。如果你使用VS 2005内置的Web服务器的话,那么你不需要以高级权限运行VS 2005,因为内置的Web服务器是以非高级权限运行的。而且这个步骤也只有在本地连接,运行/调试IIS时才需要。

我们将会更新Visual Studio 2005来提供更准确的错误消息,在将来,会以更自然的方式来向你指明以上的步骤。在目前,只要使用上面这些步骤,就可以搞定了。

希望本文对你有所帮助,

Scott

 

(思归译)

编程定制SharePoint 2007的Web Parts

【原文地址】Writing Custom Web Parts for SharePoint 2007
【原文发表日期】Saturday, September 02, 2006 10:46 AM

Sahil Malik最近发布了一篇好文章,介绍了如何使用ASP.NET 2.0来定制web part以及如何在SharePoint 2007中使用它。

正如我以前的一篇文章中提到的那样,SharePoint 2007 是建立在ASP.NET 2.0之上的, 这就意味著当你构建SharePoint站点的时候就可以使用ASP.NET 2.0的特性,譬如表单认证(Forms Authentication),母板页(Master Pages),成员(Membership),网址导航(Site Navigation),以及新的数据控件(Data Controls)等等)。无论对新的Windows SharePoint Services 3.0版本(将可以免费下载)还是Microsoft Office SharePoint Server 2007 (需要花钱购买),这都是正确的。

对开发人员来说,一个很酷的情形就是,你可以创建自定义的Web Part 控件,然后既能用于SharePoint站点,也能用于平常的单纯ASP.NET 2.0应用程序中。这让你能够重用所有这些内置的SharePoint特性,将它们用于协作,文档共享和内容管理。与此同时,你还可以添加自己定制的UI和行为,例如,假如你想把定制数据编辑和报表整合到一个网站上。

Sahil的上述文章描述了如何创建一个Web Part控件,这个控件是经编译的定制控件。现在你也能用ASP.NET的用户控件(.ascx文件)来创建Web Parts──这使得组合和封装UI功能变得更容易。一些网友在我上一篇博客帖子的评论中询问我:是否可能将以ASP.NET 2.0用户控件的形式创建的Web Parts使用于SharePoint 2007中?为此我和SharePoint产品组校对过,他们告诉我他们将支持这个情形,你可以通过添加一个附加的组件到SharePoint中的方式来实现。他们将在今年晚些时候发布一个白皮书和一个介绍怎么做的例子。

这个Channel9上的SharePoint产品组的录像,提供了SharePoint2007中一些很酷的新特性的详细信息,包括它对Wiki特性的支持。Mark Kruger在这里提供了有关SharePoint的好文章的列表。Sahil写了许多非常好的博客帖子,列举如下,它们讨论了一些定制/开发SharePoint的场景,你也许想查看一下:

Fritz Onion上个月写了一篇非常好的文章,讨论了在ASP.NET中,如何利用新的异步特性来在Web Part控件中实现高效的网络调用,而不阻塞当前的请求处理线程。这允许你同时从多个不同的web part中执行多个网络请求,并且更快更高效地呈现页面。

希望本文对你有所帮助,

Scott

标签: ,
 

(Ring译)

令人不解的 roles 属性

在 ASP.NET 2.0 的 Web.sitemap 文件中,siteMapNode 有个属性 roles ,乍一看,就象是设置此结点允许哪些角色可以访问/显示,如:

<siteMapNode url=”~/Admin/Default.aspx” title=”系统管理” description=”” roles=”Manager”> 好象就表示属于 Manager 角色的用户可以访问/显示。但我在使用的时候却发现,无论当前用户是否登录,是否属于 Manager 角色,这个菜单项都能正常显示,且能正常进入,那这个 roles 属性的意义到底在哪里呢?

 

后来查了一下才发现,要想达到我说的效果(即根据用户的角色自动显示/隐藏菜单项),必须进行如下两个步骤:

1) Web.Config 的 SiteMap 中启用安全修整,完成后如下所示:

<siteMap defaultProvider=”default”>
  <providers>
    <clear/>
    <add name=”default” type=”System.Web.XmlSiteMapProvider” siteMapFile=”web.sitemap” securityTrimmingEnabled=”true” />
  </providers>
</siteMap>

2)利用 Web.config 来实现文件或URL授权,即对 Admin 目录下的设置访问规则(可以利用 VS 2005 中的 ASP.NET 配置来实现),完成后如下所示:

<system.web>
  <authorization>
    <allow roles=”Manager” />
    <deny users=”*” />
  </authorization>
</system.web>

现在菜单终于可以自动根据用户的角色是否属于 Manager 来显示/隐藏了,但问题是,这好象完全是 Web.config 来设置的,和 siteMapNode 中的 roles 一点关系也没有,那这么 roles 的意义在哪里呢?

从 MSDN 中找出这么一段话:“当用户属于 roles 属性中列出的某一角色时,使用该属性后,ASP.NET 可避开与 siteMapNode 关联的 URL 授权限制。”,可是如果我想避开限制的话,我就根本不用在 Web.config 中设置。既然在 Web.config 中设置了限制,却又在这里用 roles 绕开限制,是不是吃饱没事干了?

现在唯一能为这个 roles 找到一个很小的用处就是,如果结点上不指定 url 属性,可以利用此属性(roles=”*”)来强制显示此结点,以便能够显示下一级结点,如:

<siteMapNode url=”” title=”系统管理” description=”” roles=”*”>
    <siteMapNode url=”~/Admin/Member_List.aspx” title=”用户管理” description=””/>
    <siteMapNode url=”~/Admin/Role_List.aspx” title=”角色配置” description=”” />
</siteMapNode>

由于 url 没有值,所以只要 Admin 目录下利用 web.config 设置了授权规则,安全调整在检查时会隐藏“系统管理”这个结点,但设置了 roles=”*” 后,可以强制显示此结点,这样下面的两个子结点(菜单项)也能正常根据角色来显示。但是,这个理由也不充分,因为将 url 设置成 “~/Admin” ,也能达到上述效果。

那么,siteMapNode 结点中的这个 roles 属性的作用到底在哪里呢?

技巧和诀窍:在ASP.NET AJAX UpdatePanel中实现对后退/前进按钮的支持

【原文地址】Tip/Trick: Enabling Back/Forward-Button Support for ASP.NET AJAX UpdatePanel
【原文发表日期】Thursday, September 14, 2006 12:25 PM

Nikhil最近写了一个好帖子,是关于一个叫做HistoryControl的支持AJAX的新ASP.NET 控件的。把它加到页面上后,允许开发人员用编程手段往浏览器的历史记录里添加逻辑视图(logical view)。这将使得支持AJAX的网站更加有用,而且遵循传统web应用所遵循的标准的前进/后退的导航惯例。

譬如,通过Nikhil的HistoryControl,开发人员可以编写类似下面这样的编码来响应一个列表的选择变动,并且把列表选择当作标识符添加到浏览器的历史记录中去:

private void ContentList_SelectedIndexChanged(object sender, EventArgs e) {
   history.AddEntry(contentList.SelectedIndex.ToString()
;
}

你一旦往历史控件里添加新项后,浏览器中的后退/前进按钮就被激活了。Nikhil的历史控件提供了一个Navigate事件,当你在浏览器里按后退/前进按钮时,这个事件就会被触发,同时它在事件处理函数的参数里提供了早先在把逻辑视图添加进浏览器历史记录时所用的那个标识符。然后你就可以使用这个标识符来把页面回复到跟这个历史记录相对应的页面状态了:

private void HistoryControl_Navigate(object sender, HistoryEventArgs e) {

    int selectedIndex 0;

    if (String.IsNullOrEmpty(e.Identifier) == false) {
        selectedIndex 
Int32.Parse(e.Identifier);
    
}

    // Update the content being displayed in the page
    
contentList.SelectedIndex selectedIndex;

    // Mark the update panels as needing an update
    
mainUpdatePanel.Update();
}

这样你的用户在使用AJAX应用时也能使用前进/后退按钮来作导航了。你可以在这里下载Nikhil的历史控件的编码,开始用在你的项目里

希望本文对你有所帮助,

Scott

(思归译)

8月9日asp.net文章链接列表

【原文地址】August 9th ASP.NET Link-Listing
【原文发表日期】Wednesday, August 09, 2006 1:24 AM

下面是我上周从网站上找到的一些我喜欢的非常好的文章和链接,我建议大家能够留出时间阅读他们: :

ASP.NET话题

使用ASP.NET 2.0发送邮件: 这是来源于Scott Mitchell的一篇好文章。他演示了如何从ASP.NET应用程序中使用.NET 2.0中的System.Net.Mail APIs发送邮件。 .

用ASP.NET 2.0发送邮件:HTML格式的邮件,附件以及如何优雅地处理SMTP异常: 这是来源于Scott Mitchell的有关发送邮件的一篇很好的续文,文章讨论了有关System.Net.Mail的一些更高级的使用场景。

UrlRewritingNet.UrlRewrite V2.0发布: 周五,Albert Weinert给我发邮件告诉我关于发布了UrlRewriting引擎最新版本的消息。UrlRewriting引擎是由他和Thomas Bandt为ASP.NET技术而写的。它供免费下载,包括例子和所有的源代码。 .

在不结合Data Source控件的情形下使用GridView控件: 已经有很多的好文章介绍了有关如何结合ASP.NET 2.0 data source控件模型来使用ASP.NET 2.0的GridView控件。 在这篇文章中,Bipin Joshi介绍了如何直接使用GridView编程,而不结合使用DataSource控件,即,直接写编码实现绑定,分页,排序等等。

在.NET中使用FlickR: 在这篇文章中,Sam Judson讨论了在.NET应用程序中如何使用FlickR提供的photo-service API编程。它允许你建立自己的照片浏览程序,以及如何向Yahoo的FlickR服务用编程手段实现上传。.

借助WebResource.axd,通过URL访问内嵌的(Embedded)资源: ASP.NET 2.0引进了一个非常有用的,称为”WebResource.axd”的特性。它可以让你避免以众所周知的目录形式手工部署脚本和图片资源,即,不再使用/aspnet_client/虚拟目录等方式的部署。Scott Mitchell在文章中介绍了它的工作原理,并且介绍了怎么利用这个特性在你自己的控件和组件里内嵌文件资源。.

ASP.NET案例研究:Session变量的丢失和AppDomain的回收: Tess出色的细解ASP.NET调试的系列帖子的又一篇,深入探讨ASP.NET中App-domains的工作原理,以及它们如何被回收以及为什么会被回收的秘密。

VS 2005 话题

在VS 2005 ASP.NET项目中如何定制组合相关文件: Visual Studio提供了在解决方案浏览器中,将某些类型的文件嵌套在其他文件下的内置支持。例如,在解决方案浏览器中,.aspx页面的代码后置文件是作为页面的子项显示的。在这篇博客帖子中,James Hebben介绍了一个灵巧的使用注册表的技巧,可以让你在VS2005中将任何文件嵌套在另外的一个文件下。他示范的例子非常有用,描述了怎么将一个特定内容的.js文件嵌套在页面或控件下。

Visual Studio 2005中的MSBuild: 这个分为13部分的系列文章描述了Visual Studio 2005中新的MSBuild build系统是如何工作的。说明一下,在VS 2005 Web应用程序项目VS 2005 Web部署项目中,MSBuild都能被使用。

将来的酷技术

Windows Workflow Foundation编程初介: Sahil Malik已经发布了几篇很酷的文章,这些文章演示了如何使用新工作流特性,这些特性将在今年秋天伴随着.NET3.0一起发布。工作流能让你以非常灵活的方式构建一系列组合操作(这样你就可以避免在逻辑中硬编码)。这个hello-world例子(以及其内链接的早期帖子)提供了深入研究这个新技术的一个捷径。

希望本文对你有所帮助,

Scott

 

(Ring译)

ASP.NET 2.0 中 AuthorizationStoreRoleProvider 可用性不高

一、授权管理概述

一般在应用程序中,比较理想、完整的授权模式就是基于角色的授权(Role Based Access Control-RBAC),它的主要目标是实现了用户与安全操作的分离,而在中间加入了角色的隔离层,从而实现了灵活性和可扩展性,具体来说,主要是这种方式:

  1. 在编写程序的时候,定义出程序的功能(或称为安全操作,如 AddBook, ModifyBook …)
  2. 在应用程序部署的时候,按照业务安全策略的要求,定义角色(如 BookManager),并定义角色与功能的对应关系
  3. 在应用程序运行期,定义可以使用系统的用户(如张三、李四),然后定义用户与角色的关系

这样通过“三个实体,两个对应”,就能找到用户和功能的关系(即用户能否执行此功能)。

二、ASP.NET 2.0 中的授权管理功能

ASP.NET 2.0中,提供了三种授权管理的提供者,分别为:AspNetSqlRoleProvider、AuthorizationStoreRoleProvider、AspNetWindowsTokenRoleProvider。

默认 AspNetSqlRoleProvider 只能提供角色与用户的实体及其对应关系,缺乏功能层次的定义和关系,所以仅能适用于有限场合,如基于 URL 的授权,或者在程序中手动使用 Roles API(Roles.IsUserInRole)来判断当前用户是否具有授权,但是这种方式的前提是角色是 Hard Code(硬编码的),以后如果角色所允许的功能发生了变化,只能通过修改程序来实现。

再来看看 Windows 2003 中附带的授权管理器(Authorization Manager,以下简称 AzMan),不可否认,它的设计比较完整地体现了 RBAC的思想,即首先定义操作,然后把操作归类形成任务(大任务也可以包括子任务),可以定义角色,然后在角色中定义其可以执行的任务或操作(大角色也可以包含小角色),最后可以应用程序中分配用户、建立角色与用户的对应关系,同时,AzMan 还提供业务规则检查的功能,即可以在任务级别定义脚本,对是否授权进行进一步的细粒度的检查,表面上看,还是比较圆满的。

但是 AzMan 的一个重大限制就是只支持 Windows 用户,它要求用户的标识为 SID(如S-1-5-21-XXXX-XXX)的格式。虽然我们可以使用 AzMan 的 API ,如 InitializeClientContextFromStringSid 来构造一个虚拟的 SID (例如,在我们的应用程序中,我们用户的 ID 为一个自增量的整数 Y,那就可以虚拟成 S-1-5-21-Y的方式)这样我们就可以利用 AzMan API 来绕开只允许Windows 用户的限制,但这些工作全部要手工完成,纯体力活,得不偿失。

本来以为 ASP.NET 2.0 的AuthorizationStoreRoleProvider 做为默认的三种 RoleProvider 之一,能为我们提供这些方面的便利功能,但在
使用之后才发现,限制依然存在,实用性仍然不够:

  1. 在定义角色时,它会把角色定义在 AzMan的“角色分配”结点上,而不是“角色定义”结点上,有点奇怪
  2. 如果使用 AspNetSqlMembershipProvider ,那么在为用户分配角色时,就会引发“帐户名与安全标识间无任何映射完成”的错误,这可以看出来 AzMan 依然是使用 Windows 用户,这一个限制很是致命,也就是说
    AspNetSqlMembershipProvider 和 AuthorizationStoreRoleProvider 是不能共用的

如果能够把 AspNetSqlMembershipProvider 中用户的 MemberId (GUID类型,格式为“XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX”)转换成 SID (S-R-I-S-S)还有可能通过 AzMan API 来利用AzMan ,但这不是通过 AuthorizationStoreRoleProvider 来进行的,而且目前我也没有找到好的、能够双向转换的方法。

三、一种实用的授权管理机制设想

目前临时想到一种即能完整实现 RBAC,又能利用 RoleProvider 的解决办法是:

  1. 利用 AspNetSqlRoleProvider 来管理 Role、定义 Role 与AspNetSqlMembershipProvider 中用户之间的关系
  2. 新增一自定义XML文件,在其中定义任务/操作列表,在编写程序时,可以在类或方法的属性中指定操作名称
  3. 同时在上述XML文件中定义 Role 与操作的对应(包含)关系
  4. 在程序中利用公用程序来检查权限,这无需写死(Hard Code)任何东西,因为是直接从当前类/方法中取出操作名称,再直接获得当前用户名,再检查第 2、3步的XML 文件文件即可。