这是一个“最佳实践”问题,但它涉及有关如何在IIS下处理数据源的理论知识。它主要涉及IIS7,但我怀疑答案与此版本并不严格相关。
IIS允许通过 IIS管理器>定义数据源。特征>连接字符串或直接插入 web.config 文件的 connectionStrings 部分。这些信息表示连接字符串,但也表示提供程序,因此看起来IIS提供了连接到数据源的所有必要信息。因此,我希望IIS能够对这些信息做一些事情 - 即管理数据源连接过程。
但是,到目前为止我找到的每个代码示例都只使用(web.config)连接字符串以自己的方式打开连接,并且通常忽略配置中设置的提供程序。这有效但......看起来更像是一种解决方法而不是预期的方式。
所以,最后我的问题是:我错过了IIS的一些数据源管理功能(在这种情况下,是否有人可以指向正确的类引用或其他文档)?
或者在IIS下运行的程序实际上是否应该自己打开数据源(在这种情况下,在IIS中将连接字符串定义为“数据源”的重点是什么,而可以使用简单的“设置”以及保持连接字符串)?
感谢您对此事的任何暗示。
答案 0 :(得分:0)
(由于> 1个月没有得到答案就是这类问题的答案,经过进一步研究,我现在能够自己回答)
似乎在IIS下运行的程序实际上需要自己管理数据源,而且有两种不同的策略可以这样做。
一种方法是将数据源视为通用的,而不暗示某种类型/提供者(如SqlServer)。
在这种情况下,应该使用System.Data.Common.DbProviderFactory
类来获取(未打开)数据库连接作为System.Data.Common.DbConnection
实例。为了提供此连接,工厂类需要连接字符串AND(连接)提供程序ID。工厂类负责通过在machine.config
文件中查找(正如Lex Li所指出的那样)来实例化该提供者的正确类。
这里connectionStrings
中的专用web.config
部分很方便,因为它的内容实际上不是“字符串”,而是包含连接字符串本身和提供者标识的结构,例如: / p>
<connectionStrings>
<add connectionString="actual SqlServer connection string" name="..." providerName="System.Data.SqlClient" />
</connectionStrings>
这是遵循此方法获取数据库连接的最简单的代码(剥离了所有错误处理,因此无法使用):
var config = WebConfigurationManager.ConnectionStrings[connectionName];
var factory = DbProviderFactories.GetFactory(config.providerName);
var connection = factory.CreateConnection();
connection.ConnectionString = config.ConnectionString;
即使完成了错误处理,也不需要编写很多代码,这可能就是为什么IIS框架中没有“标准”函数来获取连接名称并返回连接。上面的代码是IS的功能。
对于应该访问各种数据库类型的应用程序,此方法是必需的,在设计类型中未知。出于灵活性考虑,这可能是一种很好的做法,即使对于应该使用先前已知类型的特定数据库的应用程序也是如此。但是,在这种情况下,所有数据访问都应设计为通用的(例如,即使连接到SqlServer数据库,所有数据处理也必须使用Db *类而不是Sql *类。)
另一种方法是假设应用程序始终使用给定的数据库类型。这是一种不太灵活的方法,但据我所知 - 由于其简单性而非常受欢迎。
在这种情况下,可以通过实例化先前已知的类来获得连接,例如:
var connection = new SqlConnection(connectionString)
在这种方法中,不需要查找提供程序,或者在machine.config
中声明它,因为实例化的连接类在编译时是已知的。
此外,此方法不需要connectionStrings
中完全成熟的web.config
部分。实际上,让某人在连接字符串部分中定义连接,就像上面的示例完全忽略数据库提供者标识一样令人困惑,可能被视为设计不佳。
因此,我认为完全可以接受的是,在这种方法中,根本不使用connectionStrings
部分(web.config
文件),而是使用简单的“应用程序设置”来保存连接字符串。这样,web.config
中定义的所有内容实际上都被程序使用。