基本上我有一个我正在研究的网站,其中有超过8个列表框,其中包含来自数据库的信息。我目前使用SqlDataSource
因为易于使用并且正在使用它当前数据绑定到列表框。
SqlDataSource
是否一直打开连接?出于安全原因以及性能原因,我想从网站架构的角度消除任何不必要的连续打开连接。
答案 0 :(得分:1)
直接回答您的问题:不可以.SqlDataSource控件确保一旦完成需要执行的操作就关闭连接。
答案 1 :(得分:0)
我曾经使用SQLDataAdapter + SQLCommand,但现在我主要使用
using(SQLDataReader rdr = <YourSQLCommandVariable>.ExecuteReader())
{
rdr.Load(<YourDataTableVariable))
}
原因是我不确定数据适配器在数据读取器上做了什么,以允许它进行批量更新,读取和删除。如果你考虑一下,那么编写像数据适配器这样可以完成所有这些工作的类是非常困难的,而不会引入任何开销。开销可能不大,但除非我从查询中读取多个表到DataSet对象,否则我不会冒使用它的风险。
所有这一切,我怀疑,如果您在本地将所有结果数据缓存到本地计算机中,这些操作的任何开销都值得考虑。换句话说,您可以对SQL查询进行的最大改进是,如果数据不可能在某个时间范围内发生更改,则不会进行更改。如果数据每天更新一次,请将其缓存24小时或更短时间。缓存可以通过Session进行,如果它是最终用户依赖的,或者通过HttpContext.Current.Cache对象。
答案 2 :(得分:0)
听起来您可能希望在应用程序中进行一些层分离。 Web项目理想地不了解数据库。理想情况下,有一些中间层程序集可以处理与数据库的通信。然后从您的.aspx.cs或Controller中,根据您是否使用MVC,您将对中间层进行8次调用(假设它们具有不同的信息,则每个列表框一次)。中间层将返回类似List<MyObject>
的内容,然后将其绑定到列表框。
我的典型数据访问模式如下所示
using (SqlConnection conn = new SqlConnection("conn string"))
{
conn.Open();
SqlCommand command = new SqlCommand()
{
CommandText = "command text",
Connection = conn,
CommandType = CommandType.StoredProcedure //could be non-stored proc.. but would reccomend stored proc assuming SQL Server
};
command.Parameters.Add(new SqlParameter("MyParam", "param1"));
command.Parameters.Add(new SqlParameter("MyParam2", "param2"));
IDataReader reader = command.ExecuteReader();
while(reader.Read())
{
//magic here
}
conn.Close();
}