我一直认为在后面的代码中编写 SQL 查询与使用 SqlDataSource 编写相比并不好
SqlDataAdapter ad = new SqlDataAdapter("SELECT * FROM Categories", myConnection);
DataSet ds = new DataSet();
ad.Fill(ds, "Categories");
myGridView.DataSource = ds;
myGridView.DataBind();
对比
<asp:SqlDataSource ID="SqlDataSource1" runat="server"
ConnectionString="<%$ ConnectionStrings:myConnection %>"
SelectCommand="SELECT * FROM Categories" />
我觉得使用SqlDataSource 是安全的，易于维护。 我的担心是真的吗？请辩解。
【问题讨论】：
我不会在句号后面的代码中编写 SQL 查询。数据访问层怎么样？
如果您想更改后备存储，会发生什么？您将不得不重新编写所有代码隐藏。
如果您需要在多个地方使用数据，会发生什么情况？你重复了代码。
在后面的代码中编写 SQL 查询之前，您需要认真考虑如何构建解决方案。在您质疑 SqlDataSource 对象的“安全性”之前，请考虑分离和可维护性。认真的。
【讨论】：
代码隐藏中的 SQL 查询和 SqlDataSource 中的 SQL 查询几乎是等价的。
他们在安全方面都差不多；至于更容易维护，SqlDataSource 在大多数情况下可能会更容易一些。
数据访问层是首选，但 SqlDataSource 有时是一个足够好的权宜之计。如果你还没有数据访问层，我不会用卷起的报纸来打击你，因为它是简单的/一次性的。
【讨论】：
您的两种方法都不比另一种更安全。由于您的 aspx 页面的编译方式与页面背后的代码一样，因此您不会冒着仅通过使用 SqlDataSources 意外暴露 SQL 语句或数据库结构的风险。但是，安全性并不是您的主要问题——它是可维护性。
当 Microsoft 将 SqlDataSources 作为 .NET 2.0 的一部分发布时，很多人抱怨：我们认为它鼓励并强化了不良习惯。
对于任何类型的大于单个 Intranet 页面的项目，您都应该查看其行为良好的老大哥 ObjectDataSource。在使用 ODS 时，您几乎受限于为您的数据开发一个单独的模型，远离您的视野。
【讨论】：
根据我的经验，SQLDataSource 非常适合用于显示数据并可能对其进行编辑的快速一次性页面。但是一旦你进入任何一种复杂的场景（我总是这样），它很快就会崩溃。在后面的代码中同时使用 SQLDataSource 和直接 SQL 的可维护性是一场噩梦。我被 SQLDataSource 烧了很多次。
我至少会编写一个数据访问层作为您可以调用的单独程序集。如果需要，这将为您提供一种可插入的方式来更改它。更好的是 NHibernate 或 LinqToSql 之类的数据访问解决方案，它会为您处理管道并避免您自己编写整个事情。
【讨论】：
aspx 或 aspx.cs 中的 SQL 都是非常新手、不好的方法。查找 n 层/n 层设计、关注点分离和任何有关软件设计的书籍。
【讨论】：
DataSource 控件非常适合大多数事情。它们支持网格中的分页和服务器端缓存，并且可以节省访问数据库的次数。然而，一个缺点是，如果您使用 db 事务做任何复杂的事情，您将无法跨多个 sqldatasource 使用事务，至少不容易。
由于池化，两个数据源可能有不同的连接，并且在命令执行之前没有简单的方法来分配事务对象。
【讨论】：
我使用 SQLDataSources 来填充网格，需要一个简单的查询。使用存储过程而不是将查询直接放在 SQLDataSource 中解决了可重用性问题。 Telerik 控件的示例广泛使用数据源，但这可能是由于需要简单性而不是现实世界的限制。我遇到的另一个用途是放置在客户端的每个站点上的页面上，该客户端并不特别关注安全性，它使员工能够即时执行 sql。它包含一个简单的 SQL 查询 - 打开页面是检查数据库是否可访问的一种简单方法。
【讨论】：