.NET 数据访问架构指南 5
点击次数：22 次 发布日期：2008-11-26 10:38:39 作者：源代码网
|
源代码网推荐 源代码网推荐 尽管数据库链接池化提高了应用程序的整体扩展性，这也意味着你不再能够在数据库端管理安全性。这是因为为了支持链接池化，链接字符串必须是相同的。如果需要跟踪每个用户的数据库操作，那么考虑为每个操作增加一个参数，通过这个参数就可以传递用户身份，手工将用户活动记入数据库。 源代码网推荐 源代码网推荐 使用Windows 认证 源代码网推荐 源代码网推荐 在链接到SQL Server时，应当使用Windows认证，因为它提供了许多优点： 源代码网推荐 安全性易于管理，因为使用了单一(Windows)安全模型而不是分散的SQL Server安全模型。 源代码网推荐 源代码网推荐 源代码网推荐 避免了在链接字符串中嵌入用户名和密码。 源代码网推荐 源代码网推荐 源代码网推荐 用户名和密码不是以明文方式在网络中传输的。 源代码网推荐 源代码网推荐 源代码网推荐 通过密码过期期限，最小长度，多次无效登录请求后帐号锁定提高了登录的安全性。 源代码网推荐 源代码网推荐 性能 源代码网推荐 源代码网推荐 .netBeta 2版的性能测试表明，使用Windows认证与使用SQL Server认证相比，要花费更多的时间才能打开池化的数据库链接。然而，尽管Windows认证的成本较高，但与执行一个命令或存储过程所花费的时间相比，其（引起的）性能损失相对来说并不重要。结果，上面所列出的Windows认证的优点通常会稍微超过性能损失。 源代码网推荐 源代码网推荐 同样，当打开一个池化链接时，在.NET框架的RTM版本中，Windows认证与SQL Server认证的差别有望变得更不明显。 源代码网推荐 源代码网推荐 避免在中间层中冒充 源代码网推荐 源代码网推荐 Windows认证需要访问数据库的Windows帐号。虽然看上去在中间层中使用冒充更符合逻辑，但必须避免这样做，因为损害链接池化并对应用程序的扩展性产生严重影响。 源代码网推荐 源代码网推荐 为了解决这个问题，考虑对有限的Windows帐号（而不是被认证的负责人）实施冒充，每个帐号代表一个特定的角色。 源代码网推荐 源代码网推荐 例如，可以考虑下面的方法： 源代码网推荐 创建两个Windows帐号，一个用于读操作，一个用于写操作（也可以用单独的帐号映射针对特定应用程序的角色。例如，可以为互联网用户使用一个帐号，而为内部操作员和/或管理员使用另外的帐号）。 源代码网推荐 源代码网推荐 源代码网推荐 将每个帐号映射到一个SQL Server数据库角色，然后为每个角色设置所需的数据库权限。 源代码网推荐 源代码网推荐 源代码网推荐 在数据访问层中使用应用程序逻辑确定执行数据库操作时，哪个Windows帐号需要冒充。 源代码网推荐 注意 每个帐号必须是同一域或信任域中在Internet信息服务（IIS）和SQL Server中存在的域帐号；也可以是在每台计算机上创建（具有相同用户名和密码）的匹配帐号。 源代码网推荐 源代码网推荐 为网络库使用TCP/IP 源代码网推荐 源代码网推荐 SQL Server 7.0及其以后版本支持用于所有网络库的Windows认证。使用TCP/IP可以获得配置、性能及扩展性优点。关于使用TCP/IP的更多信息，见本文通过防火墙建立链接一节。 源代码网推荐 源代码网推荐 存储链接字符串 源代码网推荐 源代码网推荐 有多种方法可存储链接字符串，每种方法具有不同程度的灵活性和安全性。尽管在源代码中对字符串进行硬编码提供了最优性能，但文件系统缓存确保了与在文凭系统外部存储字符串相关的性能损失可被忽略。实际上外部链接字符串（允许管理员进行配置）所提供的附加灵活性在任何情况下都是受欢迎的。 源代码网推荐 源代码网推荐 选择存储链接字符串的方法时，首先要考虑的两个重要因素是配置的安全性与简易性，其次是性能。 源代码网推荐 源代码网推荐 可以选择将数据库链接字符串存储在下列位置： 源代码网推荐 应用程序配置文件 例如用于ASP.NET Web应用程序的Web.config文件。 源代码网推荐 源代码网推荐 源代码网推荐 通用数据链接文件(UDL) （只被OLE DB .NET 数据供应器所支持) 源代码网推荐 源代码网推荐 源代码网推荐 Windows 注册表 源代码网推荐 源代码网推荐 源代码网推荐 定制文件 源代码网推荐 源代码网推荐 源代码网推荐 COM+ 目录，通过过使用构造字符串(只用于服务组件) 源代码网推荐 使用Windows认证访问SQL Server，就可以避免在链接字符串存储用户名和密码。如果 安全需求要求更严格的方式，那么就考虑以加密格式存储链接字符串。 源代码网推荐 源代码网推荐 对于ASP.NET Web应用程序，以加密格式将链接字符串存储在Web.config文件中是一种安全而可配置的解决方案。 源代码网推荐 源代码网推荐 注意，在链接字符串中将Persist Security Info命名值设置为假，就可以阻止利用SqlConnection 或OleDbConnection对象的ConnectionString属性返回对安全敏感的内容，如密码。 源代码网推荐 源代码网推荐 下面几个小节讨论了如何用这些方法存储链接字符串，并说明了相对的优点和缺点。这使你能根据特定的应用程序环境作出相应的的选择。 源代码网推荐 源代码网推荐 使用XML应用程序配置文件 源代码网推荐 源代码网推荐 可以使用元素appSettings将数据库链接字符串存储在应用程序配置文件的定制设置部分。该元素支持任意关键字-值对，如下面的代码片段所示： 源代码网推荐 源代码网推荐 value="server=(local);Integrated Security=SSPI;database=northwind"/> 源代码网推荐 源代码网推荐 源代码网推荐 注意：appSettings元素现在在configuration元素下面，并且不能直接出现在system.web下面。 源代码网推荐 源代码网推荐 优点 源代码网推荐 易于部署。通过常规.NET xcopy部署，链接字符串随配置文件一起被部署。 源代码网推荐 源代码网推荐 源代码网推荐 通过程序易于访问。ConfigurationSettings类的AppSettings属性使得在运行时读取数据库链接字符串更为简单。 源代码网推荐 源代码网推荐 源代码网推荐 支持动态更新（仅限于ASP.NET）。如果管理员更新了Web.config文件中的链接字符串，那么下次在字符串被访问时所作出的变化生效，这对一个无状态的组件来说，就象客户再次利用组件作出了数据访问请求一样。 源代码网推荐 缺点 源代码网推荐 源代码网推荐 安全性。尽管ASP.NET Internet 服务器应用程序编程接口（ISAPI）DLL阻止了客户直接访问带.config扩展名的文件，并且NTFS文件系统权限也用于进一步限制访问，但你可能仍希望避免以明文方式将这些内容存储在前端的Web服务器上。要增加安全性，需将链接字符串以加密格式存储在配置文件中。 源代码网推荐 源代码网推荐 更多信息 源代码网推荐 源代码网推荐 利用System.Configuration.ConfigurationSettings类的AppSettings静态属性，可以获取应用程序的定制设置。如下面的代码片段所示，此处假定先前示例的定置关键字为DBConnStr。 源代码网推荐 源代码网推荐 using System.Configuration; 源代码网推荐 private string GetDBaseConnectionString() 源代码网推荐 { 源代码网推荐 return ConfigurationSettings.AppSettings["DBConnStr"]; 源代码网推荐 } 源代码网推荐 做人要厚道，请注明转自酷网动力(www.ASPCOOL.COM)。 源代码网推荐 源代码网供稿. |
