iis配置网站访问权限,网站排名怎么提升,网站建设 文件源代码约定,wordpress登录返回原文出自http://blog.sina.com.cn/s/blog_48b6cd65010004fc.html个性化 另一个新增的服务是个性化#xff0c;它提供了一种现成的解决方案#xff0c;用于解决存储站点用户的个性化设置问题。目前#xff0c;此类设置通常存储在Cookie、后端数据库或这两者中。无论这些设置存…原文出自http://blog.sina.com.cn/s/blog_48b6cd65010004fc.html个性化 另一个新增的服务是个性化它提供了一种现成的解决方案用于解决存储站点用户的个性化设置问题。目前此类设置通常存储在Cookie、后端数据库或这两者中。无论这些设置存储在何处ASP.NET 1.x都不能提供什么帮助。这需要由您来设置和管理后端数据存储以及使用经过身份验证的用户名、Cookie或其他某种机制来关联个性化数据。 ASP.NET 2.0个性化服务使得存储各个用户的设置以及随意检索这些设置变得非常容易。该服务基于用户配置文件—您可以使用新的元素在Web.config中予以定义。下面的代码节选自Web.config profile properties add nameTheme / add nameBirthday TypeSystem.DateTime / add nameLoginCount TypeSystem.Int32 defaultValue0 / /properties /profile 它定义了一个包含三个属性的配置文件一个名为Theme的字符串一个名为Birthday的DateTime值以及一个名为LoginCount的整数。后面这个属性被赋予默认值0。 在运行时您可以使用页面的Profile属性该属性引用包含该配置文件中定义的属性的动态编译类的实例来访问当前用户的这些属性。例如下列语句可从当前用户的配置文件中读取属性值 string theme Profile.Theme; DateTime birthday Profile.Birthday; int logins Profile.LoginCount; 还可以将值赋予配置文件属性 Profile.Theme SmokeAndGlass; Profile.Birthday new DateTime (1959, 9, 30); Profile.LoginCount Profile.LoginCount 1; 个性化服务的一个明显优势是强类型化。另一个优势在于个性化数据是按需读写的。请将此与会话状态无论是否使用都会将其加载并保存到每个请求中进行对比。但是个性化服务的最大优势可能在于您不必显式地将数据存储在任何位置系统会替您完成该工作并且它会永久性地存储数据以便数据在您需要时随时可用。配置文件不会像会话那样超时。 那么个性化数据存储在哪里呢这要依具体情况而定。个性化服务基于提供程序因此您可以将其配置为使用任何可用的提供程序。ASP.NET 2.0将至少附带两个个性化提供程序一个用于Access另一个用于SQL Server。如果您不另行指定则个性化服务将使用Access提供程序默认情况下该提供程序会将个性化数据存储在本地Data\AspNetDB.mdb中。您可以通过修改Web.config手动或使用Webadmin.axd来改用SQL Server数据库。如果您不希望将个性化数据存储在Access数据库或SQL Server数据库中则可以编写自己的提供程序。 默认情况下ASP.NET使用经过身份验证的用户名作为所存储的个性化数据的键但您也可以将其配置为支持匿名用户。首先通过将以下语句添加到Web.config中来启用匿名标识 anonymousIdentification enabledtrue / 然后将allowAnonymoustrue添加到您要为匿名用户存储的配置文件属性中 nameTheme allowAnonymoustrue / 现在Theme属性可以作为个性化设置使用而无论站点的调用方是否经过了身份验证。 默认情况下匿名标识使用Cookie来标识回返用户。由支持的属性可以用各种方式来配置这些Cookie。例如您可以指定Cookie名称并指明是否应该将该Cookie的内容加密。您还可以将个性化服务配置为使用无Cookie的匿名标识因此它将依靠URL Munging来标识回返用户。甚至还存在一个自动检测选项如果请求浏览器支持Cookie则使用Cookie如果不支持则使用URL Munging。 要查看个性化的工作方式请运行本文随附的下载资料中的Personalize.aspx示例。它会让站点的每个访问者选择一个主题然后记录该主题并且每当该访问者返回时都将应用该主题。请注意该主题是在页面的PreInit事件它是一个新事件它的激发时间甚至早于Init中以编程方式应用于该页面的。 在您运行该示例之前需要启用匿名标识并定义一个包含名为Theme的字符串属性的配置文件。以下代码行显示了执行上述两项任务的Web.config文件 configuration system.web anonymousIdentification enabledtrue / profile properties property nameTheme allowAnonymoustrue / /properties /profile /system.web /configuration SQL缓存依赖性 ASP.NET 1.x中令人遗憾地缺少的另一项功能是数据库缓存依赖性。可以将ASP.NET应用程序缓存中放置的项目与其他缓存项目联系起来或者与文件系统中的对象联系起来但不能与数据库实体联系起来。ASP.NET 2.0通过引入SQL缓存依赖性来纠正这一由于疏忽而造成的错误。 SQL缓存依赖性由新的SQLCacheDependency类的实例表示。它们的用法非常简单。下面的语句将一个名为ds的数据集插入到应用程序缓存中并且在该数据集和Northwind数据库的Products表之间创建依赖性 Cache.Insert (ProductsDataSet, ds, new SqlCacheDependency (Northwind, Products); 如果Products表的内容改变则ASP.NET会自动删除该数据集。 SQL缓存依赖性还可以与ASP.NET输出缓存配合使用。下面的指令指示ASP.NET缓存来自包含页面的输出直至Products表的内容改变或者满60秒为止满足任一条件即可 % OutputCache Duration60 VaryByParamNone SqlDependencyNorthwind:Products % SQL缓存依赖性适用于SQL Server 7.0、SQL Server 2000和即将问世的SQL Server 2005。对于SQL Server 2005无需进行任何准备但必须将SQL Server 7.0和SQL Server 2000数据库配置为支持SQL缓存依赖性。准备工作涉及到创建数据库触发器以及创建一个特殊的表以供ASP.NET在确定是否已经发生更改时参考。该表由一个后台线程使用可配置的轮询间隔默认为5秒钟来定期轮询。在SQL Server 2005中要检测更改既不需要特殊的表也不需要轮询。此外SQL Server 2005缓存依赖性可以在行级应用而SQL Server 7.0和SQL Server 2000缓存依赖性在表级工作。您可以使用Aspnet_regsqlcache.exe工具或Webadmin.axd来准备数据库以使其支持SQL缓存依赖性。 新的动态编译模型 ASP.NET 1.x中引入的众多创新之一是系统能够在首次访问您的代码时对其进行编译。但是只有页面能够被自动编译并且辅助类如数据访问组件必须单独编译。 ASP.NET 2.0扩展了动态编译模型以便能够自动编译几乎所有的组件。bin目录仍然保留以便实现向后兼容性但它现在添加了名为Code和Resources的目录。Code目录中的C#和Visual Basic文件以及Resources目录中的RESX和RESOURCE文件被ASP.NET自动编译并缓存在系统子目录中。此外落入Code目录中的Web服务描述语言(WSDL)文件被编译为Web服务代理而XML架构定义语言(XSD)文件被编译为类型化数据集。通过Web.config还可以扩展这些目录以支持其他文件类型。 预编译并且在不带源代码的情况下进行部署 提到动态编译与ASP.NET 1.x有关的最常见问题之一是是否可以预编译页面以避免在首次访问页面时发生的编译延迟尽管该问题本身在某种程度上无关紧要延迟非常小并且延迟的开销被成千上万甚至数以百万的后续请求所分摊但Microsoft仍然感到有必要采取相应的措施来减轻开发人员的担忧。这一“措施”就是能够通过提交对名为precompile.axd的幻像资源的请求来预编译应用程序中的所有页面。 但预编译并不仅限于此。另一个经常被请求的功能是能够将整个应用程序预编译为可以在不带源代码的情况下进行部署的托管程序集该功能在宿主方案中尤其有用。ASP.NET 2.0包含一个名为Aspnet_compiler.exe的新的命令行工具它能够执行预编译并且在不带源代码的情况下进行部署Visual Studio 2005将包含类似的功能。下面的命令将预编译Web1目录中的应用程序并且在不带源代码的情况下将其部署到Web2 Aspnet_compiler -v /web1 -p c:\web1 c:\web2 之后目标目录将包含空的ASP.NET文件ASPX、ASCX、ASIX等等以及源目录中存在的所有静态内容如HTML文件、.config文件和图像文件的副本。在不带源代码的情况下进行部署并不会为您的知识产权提供牢不可破的保护因为聪明的ISP仍然可以通过反编译生成的程序集来弄清楚应用程序的来龙去脉但是它确实对一般的代码窃取者设置了更大的阻碍。 新的代码分隔模型 ASP.NET 1.x支持两种编程模型内联模型—HTML和代码共存于同一个ASPX文件中代码隐藏模型—它将HTML分隔到ASPX文件中并将代码分隔到源代码文件例如C#文件中。ASP.NET 2.0引入了第三个模型一种新的代码隐藏形式它依赖于Visual C#和Visual Basic .NET编译器中的不完全类支持。新的代码隐藏解决了原来的代码隐藏中存在的一个恼人的问题传统的代码隐藏类必须包含受保护的字段这些字段的类型和名称需要映射到ASPX文件中声明的相应控件。 图10 显示了新的代码隐藏模型的工作方式。Hello.aspx包含页面的声明部分Hello.aspx.cs包含代码。您应该注意 Page指令中的CompileWith属性。此外请注意MyPage类中缺少的字段它们提供到ASPX文件中声明的控件的映射。旧样式的代码隐藏仍然受支持但新样式将是今后的首选编程模型。一点都不奇怪Visual Studio 2005天生就支持新的代码分隔模型。 Hello.aspx % Page CompileWithHello.aspx.cs ClassNameMyPage % html body form runatserver asp:TextBox IDInput RunAtserver / asp:Button TextTest OnClickOnTest RunAtserver / asp:Label IDOutput RunAtserver / /form /body /html Hello.aspx.cs using System; partial class MyPage { void OnTest (Object sender, EventArgs e) { Output.Text Hello, Input.Text; } } 图10 Codebehind模型 客户端回调管理器 ASP.NET 2.0中我最喜欢的功能之一就是由新的客户端回调管理器提供的“轻量级回发”功能。在过去ASP.NET页面必须回发给服务器才能调用服务器端代码。回发是低效的因为它们将包含由页面控件生成的所有回发数据。它们还强制页面刷新从而导致不雅观的闪烁。 ASP.NET 2.0引入了客户端回调管理器它使页面无需完全回发就可以回调到服务器。回调是异步的并且通过XML-HTTP来完成。它们不包含回发数据并且不会强制页面刷新。在服务器端页面像平常一样执行至PreRender事件但在即将呈现任何HTML之前停止。它们确实需要支持XML-HTTP协议的浏览器这通常意味着Microsoft Internet Explorer 5.0或更高版本。 使用客户端回调管理器涉及三个步骤。首先调用Page.GetCallbackEventReference以获取对某个特定函数可以从客户端脚本中调用该函数以执行到服务器的XML-HTTP回调的引用。ASP.NET提供了该函数的名称和实现。其次在客户端脚本中编写一个将在回调返回时调用的方法。方法名称是传递给GetCallbackEventReference的参数之一。第三在页面中实现ICallbackEventHandler接口。该接口包含一个方法—RaiseCallbackEvent当回调发生时该方法将在服务器端调用。RaiseCallbackEvent所返回的字符串将被返回到第二步所述的方法。 图11 中的代码显示了客户端回调的工作方式并且演示了它们的一个非常实际的用途。该页面显示了一个请求姓名和地址的窗体。在Zip Code字段中键入378xx或379xx邮政编码然后单击Autofill按钮City字段中将显示一个名称。值得注意的是该页面会返回到服务器以获取城市名称但它使用客户端回调而不是完全回发来完成此工作。在实际操作中它可以找到某个数据库以将邮政编码转换为城市名称。请注意该页面并不像页面在回发到服务器时通常所做的那样进行重新绘制。相反更新是快速且简洁的 % Implements InterfaceSystem.Web.UI.ICallbackEventHandler % html body h1Please Register/h1 hr form runatserver table tr tdFirst Name/td tdasp:TextBox IDFirstName RunAtserver //td td/td /tr tr tdLast Name/td tdasp:TextBox IDLastName RunAtserver //td td/td /tr tr tdAddress 1/td tdasp:TextBox IDAddress1 RunAtserver //td td/td /tr tr tdAddress 2/td tdasp:TextBox IDAddress2 RunAtserver //td td/td /tr tr tdCity/td tdasp:TextBox IDCity RunAtserver //td td/td /tr tr tdState/td n,bsp; tdasp:TextBox IDState RunAtserver //td td/td /tr tr tdZip Code/td tdasp:TextBox IDZip RunAtserver //td tdasp:Button IDAutofillButton TextAutofill RunAtserver //td /tr /table /form /body /html script languagejavascript // Function called when callback returns function __onCallbackCompleted (result, context) { // Display the string returned by the servers RaiseCallbackEvent // method in the input field named City document.getElementById (City).value result; } /script script languageC# runatserver void Page_Load (Object sender, EventArgs e) { // Get callback event reference (e.g., __doCallback (...)) string cbref GetCallbackEventReference (this, document.getElementById (Zip).value, __onCallbackCompleted, null, null); // Wire the callback event reference to the Autofill button with // an onclick attribute (and add return false to event reference // to prevent a postback from occurring) AutofillButton.Attributes.Add (onclick, cbref ; return false;); } // Server-side callback event handler string ICallbackEventHandler.RaiseCallbackEvent (string arg) { if (arg.StartsWith (378)) return Oak Ridge; else if (arg.StartsWith (379)) return Knoxville; else return Unknown; } /script 转载于:https://www.cnblogs.com/yohen/articles/877407.html
