Question

我是ASP.net的新手，我目前正在阅读有关SqlDataSource的内容并通过一些示例进行操作。我正在与一位同事交谈，他说这对于快速和脏的应用程序来说很好，但没有人会在生产/部署环境中使用它。

我真的不知道在哪里寻找或征求意见。它与我习惯的（数据访问层/业务对象/ UI）非常不同。

也许这不是一个合适的StackOverflow问题，但我不知道还能去哪里。有人对此有意见吗？有人可以提供一个或两个使用这种方法的生产/大/真棒网站吗？

就最佳实践而言 - 您建议使用哪种方法从数据库中获取数据以在您的网站中使用？

Answer 1

我从未见过使用SqlDataSource的性能问题，但我也从未将其用于大型网站，只是每天可能访问10-15次的小型企业或内部应用。它可以很容易地做很多事情（内置缓存，过滤，分页等功能）。缺点更多与维护而不是性能有关。使用SqlDataSource意味着在网站的每个页面中使用内联SQL，这显然不是企业开发的最佳实践。它不适合典型的分层开发方法，因为它会强制您将数据访问和业务逻辑嵌入到表示层中。因此，决定因素实际上与绩效无关，它更多地与复杂性有关。

Answer 2

要做基本的sql'stuff'，请使用SqlConnection和SqlDataAdapter
看到： http://www.dotnetperls.com/sqldataadapter

你也可以使用SqlCommand（许多教程 - 但是为了让你朝着正确的方向前进） http://www.csharp-station.com/Tutorials/AdoDotNet/Lesson03.aspx

确保将SqlConnection放在using语句中，以便在using语句超出范围时自动处理该对象。

在我的脑海中，您可以使用数据阅读器调用存储过程，该数据阅读器不会将结果放入数据集中，但会像流一样读取。


using (var connection = new SqlConnection(connectstring))
{
    using (SqlCommand command = new SqlCommand("dbo.SomeProc", connectString))
    {
        command.CommandType = System.Data.CommandType.StoredProcedure;
        command.CommandTimeout = 1000;
        command.Parameters.Add(new SqlParameter("@ParamName", "someValue");

        using(var reader = command.ExecuteReader())
        {
            while (dataReader.Read())
            {
                string someValue = dataReader["SomeColumnName"];
            }
        }
    }
}

Answer 3

我没有太多可以添加到Joel所说的内容，但这是其中一个问题，它得到的答案越多，它就越有帮助。

我有三个仍在使用SqlDataSource控件的生产站点。它们自2006年初开始运行。它们即将进行大修并转移到MVC，但这不是因为它们遇到了性能问题。这是因为客户希望他们在5年后更新并延长。它们不是庞大的繁忙站点，但SqlDataSources可以在其他任何地方使用。它们只是围绕ADO.NET的包装器。它们可能比大多数ORM更高效。

我在这些网站中没有内联SQL。 DataSource控制调用存储过程。在这方面，数据访问层存在于一个地方 - 数据库本身。

生产代码中的SqlDataSource示例

3 个答案: